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(B) All the claims are believed to be directed to a single invention. If the 
examiner determines that all the claims presented are not obviously directed to a single 
invention, then Applicant will make an election without traverse as a prerequisite to the grant of 
special status where the specific grouping of claims will be determined by the examiner. 

(C) A pre-examination search was made by a foreign patent office in 
connection with a corresponding foreign application. The corresponding foreign application is 
European Patent application No. EP01 1 17862, a copy of the first page of which is provided 
herewith for identification purposes as Exhibit A. A search was performed by an examiner in the 
European Patent Office for the European patent application, and reported in a communication 
dated October 29, 2003 ("EPO search report"), submitted herewith as Exhibit B. The following 
references were identified in the EPO search report: 

(1) U.S. Pat. No. 6,1 19,160 to Zhang et al.; 

(2) Rigney, C, "RFC 2866: RADIUS Accounting" (June 2000); 

(3) Mills, C, "RFC1272: INTERNET Accounting: Background" 
(November 1 99 1 ); and 

(4) PCT International Publication No. WO 97/22936. 

(D) The references cited in the EPO search report have been made of record in 
an Information Disclosure Statement mailed December 8, 2003. Copies of the references are 
enclosed herewith for convenience, collectively identified as Exhibit C. 

(E) Set forth below is a detailed discussion of the references, pointing out with 
particularly how the claimed subject matter, recited in the claims as amended per the preliminary 
amendment filed herewith, is distinguishable over the references. 

Claimed Subject Matter of the Present Invention 

The present invention is directed to an accounting system for data storage 
systems. Briefly, the present invention provides accounting based on the number of times an 
accounting object is accessed, and on the amount of data transfer that occurs with the accounting 
object. 

Claim 1 recites an accounting system including host computers, an accounting 
server, a storage control device, and storage devices for storing data. The accounting system 



Page 2 of 10 



Appl. No. 09/915,692 PATENT 
Petition to Make Special 

comprises "accounting data generating means for generating accounting data comprising a 
number of times of access and a data transfer quantity for each of one or more accounting subject 
control units." The accounting system recited in claim 1 further comprises a "transfer means for 
informing said accounting server of said accounting data generated by said accounting data 
generating means." Claim 2 recites that the accounting subject control units "includes at least 
one of a host computer, a World Wide Name, a channel port, a storage device and an in-storage- 
device area." 

A further aspect of the invention is the storage control device "is associated with a 
service processor and includes transfer means for informing said service processor of said 
accounting data" as recited in Claim 3. Still a further aspect of the invention includes "means for 
setting an upper limit of said accounting data . . . made to operate from at least one of said 
accounting server and said service processor" as recited in Claim 4. The upper limit value can be 
"determined on the basis of a predetermined period which includes, as a unit, at least one of a 
day, a week, a month, and a year" as recited in Claim 5. The storage control device can include 
means which "does not accept said data input/output request larger than said upper limit value" 
as recited in Claim 6. 

Claim 12 recites a method for making accounting for a plurality of host computers 
in a storage-related accounting system. Recited steps include "designating accounting subject 
control units." Claim 13 recites that accounting subject control units "include host computers, 
World Wide Names, channel ports, and storage areas in storage devices." The method recited in 
Claim 12 further includes "for at least some of said accounting subject control units, determining 
an upper limit value for a number of times of access and for an upper limit value for a data 
transfer quantity" and "generating accounting data of said accounting subject control units in 
accordance with said upper limit values." 

U.S. Patent No, 6,119.160 to Zhang et al. 

The reference to Zhang et al. relates to time-based and byte-based accounting for 
start/stop events. Col 7, lines 5 - 12. Events include the user account logon, service 
establishments, and the Point to Point protocol (PPP) connections within the network. A counter 
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tracks the duration of sessions and connections and the byte-count associated with the specified 
session or connection. Col 2, lines 20 - 30. 

Figs 2 A and 2B constitute a flow chart of a typical logon-to-logoff session, 
showing how accounting is performed. The description is given from col. 3, line 64 to col. 8 3 
line 20. Highlights of the flow chart include the accounting events such as logon, service logon 
(establishment), service connection, and the respective reverse activities (e.g., logoff). 
Accounting for a logon event begins at step 46, and is described beginning at about col. 4, line 
36. Accounting for a service logon event begins at step 72, and is described beginning at about 
col. 5, line 20. Accounting for a service PPP connection event begins at step 78, and is described 
beginning at about col. 5, line 44. 

Accounting for a disconnect from a PPP connection begins at step 84, and is 
described at about col. 6, line 10. Attributes associated with this accounting event are shown in 
col. 6, lines 23 - 53. Of note is the Acct-Session-Time which is the length of the session in 
seconds. 

Accounting for the termination of a service begins at step 90, and is described at 
about col. 6., line 64. The attributes for this event are shown in col. 7, lines 10 and following. 
Of note is the Acct-Session-Time which measures the session duration in seconds. 

Finally, accounting for logoff begins at step 96, and is described at about col. 7, 

line 32. 

Zhang et al. do not appear to show the subject matter recited in the pending 
claims. They do not teach "accounting data comprising a number of times of access and a data 
transfer quantity for each of one or more accounting subject control units." Claim 1. Zhang et al. 
clearly disclose time-based accounting, but do not show number-of-times-of-access accounting. 
Moreover, the time-based attributes for the logoff and disconnection events do not suggest 
accounting based on a number of times of access to an accounting subject unit. 

Zhang et al. do not teach "determining an upper limit value for a number of times 
of access and for an upper limit value for a data transfer quantity" of an accounting subject unit, 
nor do they teach "generating accounting data of said accounting subject control units in 
accordance with said upper limit values." Claim 12. First, Zhang et al. teach to simply monitor 
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the time duration of a session; they do not teach placing an upper limit to a session. Secondly, 
monitoring a duration of time does not suggest monitoring the number of times of access to an 
accounting subject unit. 

RFC 2866: RADIUS Accounting by Rignev. C. 

This reference describes a protocol for carrying out accounting information 
between a network access server and a shared accounting server. The protocol is known as 
RADIUS (remote authentication dial-in user service). This reference discloses an extension of 
the RADIUS protocol to cover delivery of accounting information from the network access 
server to a RADIUS accounting server. Page 2 

Terminology used in the document is discussed on page 3. Of note is the term 
"session" of a service, characterized by a beginning-of-session and an end-of-session. A user 
may have multiple sessions in parallel or in series, with each session generating a start and a stop 
accounting record with its own session ID. 

An Accounting Start packet is transmitted at the start of a service delivery. 
Conversely, an Accounting Stop packet is sent at the end of service delivery. Page 4. 

Packet format is described on pages 5-7. Packet types are discussed on pages 7 - 
9. A packet is either an Accounting-Request (page 8), or an Accounting-Response (page 9). 

As shown on page 6, a packet may have attributes. Attributes carry the specific 
details for the two packet types. Page 10. The attributes described in this reference are shown 
on page 1 1 . 

A noteworthy attribute is the Acct-Session-Time attribute discussed on page 17. 
This attribute indicates how many seconds the user has received a service. 

The attribute Acct-Multi-Session-Id discussed on page 21 make it easy to link 
together multiple related sessions. Each session linked together would have a unique Acct- 
Session-Id (see page 15), but the same Acct-Multi-Session-Id. 

Pages 23 - 25 show a list of attributes which may be found in Accounting-Request 

type packets. 



Page 5 of 10 



Appl. No. 09/9 1 5,692 PATENT 
Petition to Make Special 

This reference does not appear to show the subject matter recited in the pending 
claims. It does not teach "accounting data comprising a number of times of access and a data 
transfer quantity for each of one or more accounting subject control units." Claim 1. The Acct- 
Session-Time attribute does not measure number of times of access . None of the other attributes 
listed on page 1 1 and on pages 23 - 25 show or suggest an attribute that measures number of 
times of access . 

This reference does not appear to disclose "determining an upper limit value for a 
number of times of access and for an upper limit value for a data transfer quantity" of an 
accounting subject unit, nor do they teach "generating accounting data of said accounting subject 
control units in accordance with said upper limit values." Claim 12. A review of the attributes 
does not show any attributes for setting a limit for number of times of access . A Port-Limit 
attribute is identified on page 25, but is not otherwise described. 

Portions of the reference appear to have been identified by the examiner who 
prepared the EPO search report, by underlining text and annotating the margins. The identified 
portions include pages 2 - 4, 6, 8 - 10, 13, and 26. A review of these identified portions does not 
reveal any teaching of the subject matter recited in the claims. 

RFC 1272: INTERNET Accounting: Background by Mills et al. 

This reference provides background information for the "Internet Accounting 
Architecture." The focus is on defining METER SERVICES and USAGE REPORTING. A 
goal of a usage reporting architecture is to define a generalized accounting management activity, 
including calculations, usage reporting to users and providers and enforcing various limits on the 
use of resources. The authors discuss the motivation for usage reporting, on pages 2 and 3. 

Accounting requirements are driven by policy, and vice-versa where policy is 
influenced by available management and reporting tools. Section 3.2, pages 4 - 6. The authors 
note that existing accounting policies for network traffic are usually based on parameters which 
change seldom; e.g., line speed of a physical connection which leads to FLAT-FEE billing. An 
incentive for this type of billing includes predictable monthly charges. Another inventive is no 
overhead is incurred for managing or tracking packet counts and usage-based reports. The 
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authors further note that USAGE-SENSITIVE charges may be preferred, however, by low- 
volume users. 

In Section 3.3 (pages 6 - 8), the authors discuss some underlying assumptions 
they make to simplify the environment for developing an architecture for internet usage 
accounting. 

A METER is a process which examines packets on a communications medium, 
and records aggregate counts of packets. Page 8. Meter placement is discussed on pages 9-10. 
Meter types include network monitors, line monitors, router-integral monitors, and router 
spiders. Page 10. The GRANULARITY of the information collected by a meter is controlled by 
the following considerations, described on pages 11-12. The ENTITY that is metered affects 
granularity. A PORT entity in the network is the coarsest granularity, while a HOST entity and a 
USER entity are at the fine-end of the granularity scale. The ATTRIBUTE categorizes packets 
into types; at the finest granularity, packets are individually identified by type of service being 
communicated. Other factors include: VALUES with units such as simple counters (packet, 
byte) and start/stop time; and REPORTING INTERVAL. Ways of collecting metering 
information are discussed in Section 4.4, pages 12 - 14. 

A series of examples to illustrate the kinds of data that might be of interest to 
service providers and consumers is described in Section 5, on pages 14-17. In a single LAN 
service (Section 5.1), flows between individual host pairs can be measured. In an extended LAN 
(Section 5.2), an administrator might collect flow information between subnets in the LAN, 
while subnets might want to keep track of flows between hosts. Section 5.3 and Section 5.4 
discuss typical data of interest at the regional and national backbone levels, respectively. 

The authors provide a brief discussion about future issues: the need for 
application standards for accounting systems; quotas; session accounting, which refers to 
detailed auditing of individual sessions across the internet; application level accounting, which 
refers to hosts and proxy agents performing their own accounting; and the user. 

From the foregoing summary of the Mills et al. reference, it appears there is no 
discussion as to elements of the present invention as recited in the pending claims. The reference 
does not teach "accounting data comprising a number of times of access and a data transfer 
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quantity for each of one or more accounting subject control units." Claim 1. The reference does 
not appear to disclose "determining an upper limit value for a number of times of access and for 
an upper limit value for a data transfer quantity" of an accounting subject unit, nor do they teach 
"generating accounting data of said accounting subject control units in accordance with said 
upper limit values." Claim 12. 

PCT Published Application: WO 97 22936 to Eggleston et al. 

Eggleston et al. describe a system for monitoring and controlling the amount of 
communications between a remote unit and a communication server. Five embodiments are 
disclosed. Pages 4-6. A virtual session manager is provided, in a first embodiment, to establish 
and maintain a session-less communication path with a first device and a session-oriented path 
with a second device. In a second embodiment, a pre-stage filter is provided to apply user- 
defined filter parameters on data being transferred between a remote unit and a server unit. In a 
third, embodiment, a select and summary listing is used to allow a user to review and request 
filtered data. In a fourth embodiment, an optimized technique for replying to messaging is 
provided. In a fifth embodiment, a rate governor monitors and controls the amount of 
communications between remote and server units. 

Eggleston et al. disclose the use of thresholds in the rate governor to alert and 
restrict communications. Kindly refer to pages 24 and following. The rate governor tracks the 
approximate time and/or expense for client use. This includes the timing of a circuit-switched 
connection, or timing or estimating size of transmitted packets. Time or cost thresholds can be 
used to trigger alerts to warn the user of remaining time or charge. 

A review of Eggleston et al. does not appear to show the subject matter recited in 
the pending claims. Eggleston et al. do not teach "accounting data comprising a number of times 
of access and a data transfer quantity for each of one or more accounting subject control units." 
Claim 1. 

Eggleston et al. do not appear to disclose "determining an upper limit value for a 
number of times of access and for an upper limit value for a data transfer quantity" of an 
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accounting subject unit, nor do they teach "generating accounting data of said accounting subject 
control units in accordance with said upper limit values." Claim 12. 
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to Point protocol (PPP) connections between the gateway 
device and public and private domains within the network. 
The counter is capable of tracking the duration of sessions 
and connections and the byte -count associated with the 
specified session or connection. The gateway device com- 
municates with an accounting server which stores the 
accounting requests and matches start requests with subse- 
quent stop requests. 
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MULTIPLE-LEVEL INTERNET PROTOCOL 
ACCOUNTING 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to an accounting method and 
apparatus used in a computer network. More particularly, the 
present invention relates to a method and apparatus for 
generating time-based and/or byte-based accounting for 
various significant start/stop events using standard Internet 
protocol, such as the Remote Authentication Dial-In User 
Service (RADIUS) protocol. 

2. Background 

The ability to provide computer networking capabilities to 
the home personal computer (PC) is typically provided by 
telephone companies (Telcos) or commercial Internet Ser- 
vice Providers (ISPs) who operate network access points 
along the information superhighway. Network access points 
which are commonly referred to as Points of Presence or 
PoPs are located within wide area networks (WAN) and 
serve to house the network interfaces and service compo- 
nents necessary to provide routing, bridging and other 
essential networking functions. It is through these network 
access points that the user is able to connect with public 
domains, such as the Internet and private domains, such as 
the user's employer's intra-net. 

Currently, Telcos and ISPs are limited in the means by 
which they can charge customers for their product. 
Basically, Telcos and ISPs are confined to either charging a 
flat fee, typically on a monthly basis, thus allowing the user 
unlimited network access for the specified period, or charg- 
ing the user on a rate basis, typically an hourly rate. These 
billing schemes are primitive because the current capabili- 
ties possessed by the Telcos and ISPs provide only a 
simplified means of accounting for the events which a user 
undertakes during the time the user is logged on to the access 
point. Current technology only allows for the Telco or ISP 
to account for the duration of the period from when a user 
logs-on to the Telco or ISP and when the user subsequently 
logs-off. 

As an example, a user implements a "dashboard" appli- 
cation on their host/computer which requires them to input 
identification and authorization information. This informa- 
tion is then sent via modem and telephone line to the Telco 
or ISP operated access point, A network access server (NAS) 
receives the identification and authorization information and 
proxies it to an authentication, authorization and accounting 
server. Once the server verifies the user authentication and 
authorization it grants the user logon access to downstream 
public and private networks. At this point a counter within 
the NAS is engaged which begins tracking the duration of 
the log-on session as well as the byte count encountered 
during the session. Subsequently, when the user desires to 
log off or a log off is warranted by other means outside of 
the control of the user, the counter within the NAS is 
disengaged and the appropriate accounting data is forwarded 
to the accounting server. 

The Telco or ISP would benefit from having a more 
developed accounting scheme which allows for the tracking 
of various major events which occur during the life of the 
logon session. For example, through the Telco or ISP the 
user is capable of connecting with various services (e.g. the 
Internet, private intra nets, private pay-for-access domains). 
Additionally, once the user has initialized or connected to 
the service, the individual PPP connections and PPP discon- 
nections in to and out of the service can be accounted for. 
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Such multiple-level accounting would provide the Telco or 
ISP with flexibility in devising sophisticated rate schemes. 
The ISPs and Telcos would no longer be restricted by rate 
schemes solely based on account logon and account logoff, 

5 but rather customers could be charged in accordance to the 
specific services which they access and the duration, byte- 
count or quantity of the connections to those service. The 
ability to account for service establishment and PPP con- 
nections allows Telcos and ISPs to offer their customers (i.e. 

10 computer users) cost effective access to communities of 
interest (i.e. those domains sites which are designated as 
pay-per-use.) Telcos and ISPs would be afforded the capa- 
bility to provide detailed billing information and create 
various service options. 

15 

BRIEF DESCRIPTION OF THE INVENTION 

The present invention is a method and apparatus for 
providing computer network access points the capability for 
multiple-level accounting. A gateway device located at the 

20 access point is capable of generating Internet protocol 
accounting start and stop requests based on various events 
that are to be accounted for when a user accesses a network. 
These events include the user account logon, the service 
establishments and the Point to Point protocol (PPP) con- 

25 nections between the gateway device and public and private 
domains within the network. The counter is capable of 
tracking the duration of sessions and connections and the 
byte-count associated with the specified session or connec- 
tion. The gateway device communicates with an accounting 

30 server which stores the accounting requests and matches 
start requests with subsequent stop requests. 

OBJECTS AND ADVANTAGES OF THE 
INVENTION 

35 

Accordingly, it is an object and advantage of the present 
invention to provide a method for network access point 
maintainers to implement multiple-level accounting which 
thereby provides the capability for detailed billing records 
40 and create various service options. 

Another object and advantage of the present invention is 
to provide for a accounting system within a PoP of a 
computer network which is capable of multiple-level 
accounting. 

45 Another object and advantage of the present invention is 
to provide a computer network service provider the capa- 
bility to account for account logons, service establishments 
and PPP connections. 

Another object and advantage of the present invention is 

50 to provide a secured means for providing multiple-level 
accounting by implementing means for retrying accounting 
requests and providing for secondary hardware back-up. 
Yet another object and advantage of the present invention 

55 is to allow for the accounting request packets to use eight 
byte integers thus operating at 1.5 meg bits/second and 
eliminating the concern over counter overflow. 

These and many other objects and advantages of the 
present invention will become apparent to those of ordinary 

60 skill in the art from a consideration of the drawings and 
ensuing description. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic drawing of a computer network 
65 embodying a method for multiple-level Internet protocol 
accounting in accordance with a presently preferred embodi- 
ment of the present invention. 
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FIGS. 2A and 2B are a flow diagram of a method for 
multiple-level Internet protocol accounting in a computer 
network in accordance with a presently preferred embodi- 
ment of the present invention. 

FIG. 3 is a schematic of an accounting system within a 5 
computer network which employs multiple-level Internet 
protocol accounting in accordance with a presently preferred 
embodiment of the present invention. 

FIG. 4 is a schematic of a computer network system 
which employs multiple-level Internet protocol accounting 10 
in accordance with a presently preferred embodiment of the 
present invention. 



DETAILED DESCRIPTION OF THE PRESENT 
INVENTION 
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Those of ordinary skill in the art will realize that the 
following description of the present invention is illustrative 
only and is not intended to be in any way limiting. Other 
embodiments of the invention will readily suggest them- 2Q 
selves to such skilled persons from an examination of the 
within disclosure. 

The present invention allows the computer network ser- 
vice provider to assemble accounting records for three 
separate accounting events. These events are the initial 25 
network account logon/logoff, the service establishment/ 
termination and the individual connection starts and stops to 
a specified service. The present invention is capable of 
accounting for both the time duration for an event and for the 
byte count encountered during a given event. 30 

In a presently preferred embodiment of the present 
invention, a method for multiple-level internet protocol 
accounting is illustrated by the computer network schematic 
of FIG. 1 and the flow diagrams of FIGS. 2A and 2B. In the 
simplified schematic of a computer network 10 shown in 35 
FIG. 1, the host 12 is able to connect with various private 
and public network domains 14 and 16, including the 
internet through an access point 18. The access point 18 is 
typically a computer network service provider, such as a 
telephone company (Telco) or commercial internet service 40 
provider (ISP). The access point serves as a link in the 
overall network scheme and houses various network inter- 
faces and service components capable of routing and trans- 
ferring data to and from various points on the network. 
Shown in FIG. 1 are a service selection gateway (SSG) 20, 45 
such as the Cisco model 6510, manufactured by Cisco 
Systems, Inc. of San Jose, Calif, and an authentication, 
authorization and accounting (AAA) server 22, such as 
Cisco ACS or Cisco Secure, manufactured by Cisco 
Systems, Inc. of San Jose, Calif. These devices are located 50 
within the access point 18 and are instrumental in carrying 
out the multiple-level internet protocol accounting method 
of this presently preferred embodiment. The AAA server 22 
may accommodate several client SSG's simultaneously and 
communicate with one another according to a standard 55 
Internet protocol. For the presently preferred embodiment of 
this invention, the Remote Authentication Dial-In User 
Service (RADIUS) protocol is used as the communication 
protocol between the SSG 20 and the AAA server 22. Those 
of ordinary skill in the art will realize that other internet 60 
protocols can be used as acceptable communication means 
between the various communication devices which encom- 
pass the computer network 10. 

At step 30 of FIG. 2A, the user of the host computer 12 
initiates a dashboard application program as a means of 65 
gaining access to a desired computer network. The dash- 
board application program will typically require the user to 



enter some form of user identification and authentication 
information, most generally, a user-name and a private 
password. It may be possible for the host computer to store 
such information in memory and provide this information to 
the application program automatically upon initiating the 
program. The application program will then contact a com- 
puter network service provider, typically a telephone com- 
pany (Telco) or commercial internet service provider (ISP), 
via a modem and telephone line. At step 32, the host 12 
sends to the computer network service provider a RADIUS 
logon request data packet containing the user identification 
and authentication information. This data packet can come 
directly from the host computer 12 or, it is also within the 
inventive concept herein disclosed, to have this packet sent 
from an external web server. 

At step 34, the computer network service provider 
receives the RADIUS logon request data packet at the SSG 
20 and initiates a RADIUS account logon access request 
packet for host authentication. At step 36, the RADIUS 
account logon access request packet is directed to the AAA 
server 22 where, at step 38, the access request packet is 
matched against unique user profiles in memory to verify the 
authenticity of the user host 12. Next, at step 40 the AAA 
server 22 sends an authentication reply back to the SSG 20 
which confirms the authentication and lists the services 
available for a particular user. If the authentication reply 
indicates that the authentication process was successful then, 
at step 42, the SSG 20 logons on the host 12 by sending an 
access-accept packet from the SSG 20 to the host 12 
informing the user that the logon process has been com- 
pleted and displaying the available services on the user's 
dashboard. If the authentication reply indicates that the 
authentication process was unsuccessful then, at step 44, the 
SSG 20 sends a prompt back to the host 12 notifying the user 
that the authentication process was unsuccessful. 

Once the SSG 20 logons on the host 12, at step 46 the SSG 
20 generates an account logon accounting start request and, 
at step 48, this accounting start request is sent to the AAA 
server 22. In the preferred embodiment the RADIUS 
account logon accounting start request will have the follow- 
ing attributes associated with the record: 

Acct-Status-Type=Start 

NAS-IP-Address=ip address 

User-Name => u username M 

Acct-Session-Id="session id" 

Framed-IP- Address-user ip 

Proxy-State="n" 

where: 

ip address=IP address of the SSG interface card 1. 

useraame=Name used to log on to the service provider 
network 

session id=Session Number 

user ip«IP address of the user's system 

noAccounting record queuing information 
Once the account logon accounting start request has been 
completed, at step 50, the host 12 is capable of initiating a 
service logon request. At step 52, the service logon request 
is sent from the host 12 to the computer network service 
provider where it is received by the SSG 20. The SSG 20 
makes an initial determination, at step 54, to determine if the 
requested service profile is available within the SSG 20. If 
the service profile pre-exists in the SSG 20 then a determi- 
nation is made, at step 64, as to whether the user has 
authorization to access the desired service. If no service 
profile exists, then at step 56, the SSG 20 prepares a 
RADIUS service access request packet as a means for 
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verifying the authorized services available for the given user. 
The RADIUS service access request packet is sent, at step 
58, to the AAA server 22 where the information in the 
service access request packet is used to locate, at step 60, 
service profile stored in the memory of the AAA server 22. 5 
Once the service profile is found, it is forwarded to the SSG 
20 at step 62 and at step 64 a determination is made as to 
whether the user has authorization to access the desired 
service. If no match to the desired service is found within the 
user profile then authorization to access the service is 10 
withheld and, at step 66, a prompt is sent to the host 12 
informing the user that service authorization is denied. If the 
service to which the user 12 desires access to is found within 
the user profile then the SSG 20 at step 68, logs the user on 
to the desired service. The connection to the service may be 15 
accomplished by various means, including but not limited 
to, an L2TP (Layer Two Tunneling Protocol) tunnel con- 
nection 24 or a standard Internet (packet-forward) connec- 
tion 26 via a leased line. 

Once the service logon is successfully completed, at step 20 
70, the SSG 20 determines whether a pre-existing service 
connection exists (typically, generated by any other host 
which connects through this particular access point). If a 
service connection is pre-existing then no need exists to 
generate a service accounting start request packet because 25 
the AAA server 22 will already have such stored in memory. 
If no pre-existing service connection exists, then at step 72, 
the SSG 20 generates a service accounting start request 
packet and at step 74 this request is sent from the SSG 20 to 
the AAA server 22. In the preferred embodiment the 30 
RADIUS service accounting start request packet will have 
the following attributes associated with the record: 

Acct-Status-Type=Start 

NAS-IP-Address=ip address 

User-Name="service" 35 

Acct-Session-Id="session id" 

Proxy-State="n" 
where: 

service=Name of the service profile. 40 

ip_address=IP address of the SSG interface card 1. 

session id=Session Number. 

n=Accounting record queuing information. 
Once the service establishment is completed, the user, at 
step 76, is connected with the home gateway 28 of the 45 
desired service. When this type of Point to Point Protocol 
(PPP) connection is made with the home gateway 78 of the 
desired service, it triggers the SSG 20, at step 80, to generate 
a connection accounting request packet and forward this 
request to the AAA server 22, step 80. In the preferred 50 
embodiment the RADIUS connection accounting start 
request packet will have the following attributes associated 
with the record: 

Acct-Stalus-Type=Start 

NAS-IP-Address*=ip_address 55 

ser-Name«"username" 

Acct-Authentic= RADIUS 

Acct-Session -Id =" session id" 

Se rv ice -I nfo»" service" 

Service-Info~"hg username" 

Service-Info="type" 

Proxy-State="n" 

where: 

ip_address«lP address of the SSG interface card 1. 65 
username=Name used to log on to the service provider 
network 
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session id=Session Number 

service=Name of the service profile. 

hg username=The username used to authenticate the 

user with the home gateway. 
type=TT — Tunneled connection. 

TI — Internet (packet-forward) connection. 
n=Accounting record queuing information. 

Once a user desires to disconnect from an open PPP 
connection and, at step 82, the disconnect is executed, the 
SSG 20 generates a connection accounting stop request 
packet, step 84. While these packets will typically be gen- 
erated due to a host-request disconnect command, it is also 
possible to generate the packets when a disconnect is 
prompted by other events outside the control of the user, 
such as, a lost-carrier, a lost-service or a session-timeout. 
Once the connection account stop request packet is 
generated, at step 86, the packet is forwarded to the AAA 
server 22 where it is coupled with the initial connection start 
request for accounting and filing purposes. In the preferred 
embodiment the RADIUS connection accounting stop 
request packet will have the following attributes associated 
with the record: 

Acct-Status-Type=Stop 

NAS-IP-Address=ip address 

User-Name="username" 

Acct-Input-Octets«in-bytes 

Acct-Output-Octets=out bytes 

Acct-Session-Time=time 

Acct-Terminate-Cause=cause 

Acct-Session-Id="session_id" 

Service-Info="service" 

Service-Info="hg username" 

Service-Info="type" 

Proxy-State="n" 

where: 

ip_address=IP address of the SSG interface card 1. 
username=Name used to log on to the service provider 
network. 

in__bytes=Number of inbound bytes. 

out_bytes=Number of outbound bytes. 

time=Length of session in seconds. 

cause=Cause of account termination. These include: 
— Lost-Carrier — Lost-Service — User-Request — 
Session-Timeout 

session id=Session Number. 

service=Name of the service profile. 

hg username =The username used to authenticate the 

user with the home gateway. 

type=TT — Tunneled connection. 

TI — Internet (packet-forward) connection. 

n»Accounting record queuing information. 
Once the host terminates the PPP connection, at step 88, 
the SSG 20 determines whether any remaining connections 
exist to the service. If the host 12 or other hosts connected 
through this access point have current connections existing 
with this service, then no need exists at this time to generate 
a service accounting stop request packet. The service 
accounting stop request packet will be generated only when 
no existing connections exist through the service connec- 
tion. If the SSG 20 determines that no other then-existing 
connections exist through the service connection then, at 
step 90, the SSG 20 generates a service accounting stop 
request packet. While these service stop request packets will 
typically be generated as a result of a host-request discon- 
nect command, it is also possible to generate the packets 
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when a disconnect is prompted by other events outside the 
control of the user, such as, a lost-carrier, a lost-service or a 
session-timeout. Once the service account stop request 
packet is generated, at step 92, the packet is forwarded to the 
AAA server 22 where it is coupled with the initial service 
start request for accounting and filing purposes. In the 
preferred embodiment the RADIUS service accounting stop 
request packet will have the following attributes associated 
with the record: 

Acct-Status-Type=Stop 

NAS-IP-Address=ip_address 

User-Name="service" 

Acct-Input-Octets=in-bytes 

Acct-Output-Octets=out_bytes 

Acct-Session-Time=time 

Acct-Terminate-Cause=cause 

Acct-Session-Id="session id" 

Proxy-State="n" 

where: 

service=Name of the service profile. 
ip_address=IP address of the SSG interface card 1. 

in bytes=Number of inbound bytes. 

out_bytes=Number of outbound bytes. 
time=Length of session in seconds. 
cause=Cause of account termination. These include: 
— Lost-Carrier — Lost-Service — Host-Request — 
Session-Timeout 

session id=Session Number. 

n= Accounting record queuing information. 
Finally, once the host desires to logoff from the network 
account and, at step 94, the logoff is executed, the SSG 20 
generates an account logoff accounting stop request packet, 
step 96. While these packets will typically be generated due 
to a user-requested logoff command, it is also possible to 
generate the stop packets when a logoff is prompted by other 
events outside the control of the user, such as a session 
timeout. Once the account logoff accounting stop request 
packet is generated, at step 98, the packet is forwarded to the 
AAA server 22 where it is coupled with the initial account 
logon accounting start request for further accounting and 
filing purposes. In the preferred embodiment the RADIUS 
account logoff accounting stop request packet will have the 
following attributes associated with the record: 
Acct-Status-Type=Stop 
NAS-IP-Address=ip_address 
User-Name="username" 
Acct-Session-Time=time 
Acct-Termin ate -Cause =cause 
Acct-Session-Id=user_id 
fra med- 1 P- Address=user_ip 
Proxy-State="n" 
where: 

ip address=IP address of the SSG interface card 1. 

username=Name used to log on to the service provider 
network. 

time=Length of session in seconds. 

cause=Cause of account termination. These include: 

— User-Request — Session-Timeout 
session_id«Session Number. 

user ip«IP address of the user's system. 

n= Accounting record queuing information. 
In another preferred embodiment of the present invention 
the method for multiple-level accounting can include an 
additional accounting session implemented to provide peri- 
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odic update information to the AAA server 22. These 
periodic accounting update request packets contain infor- 
mation which, typically, mirrors the data found in account 
logoff accounting stop request packets and serve as an added 
measure of security should system errors, transmission 
errors, or the like, prevent the actual account logoff account- 
ing stop request from being either properly generated at the 
SSG 20 or properly sent to the AAA server 22. The Telco or 
commercial ISP is capable of defining the attributes associ- 
ated with the periodic accounting update request and defin- 
ing the time period between such requests. 

Additional security measures can also be imposed by the 
SSG 20 to insure that accounting request packets are prop- 
erly received by the AAA server 22. These security measures 
include defining within the SSG 20 scheme a retry value and 
an interval between retry to be employed when the SSG 20 
makes a determination that an accounting request packet 
was not properly delivered to the AAA 22 server. The retry 
value and the interval between retry are SSG-user config- 
urable. 

In another embodiment of the present invention, a net- 
working event metering system using the multiple level 
accounting of the present invention is detailed in FIG. 3. In 
this configuration the networking event metering system 120 
includes a gateway device 122. The gateway device 122 is 
in communication with a plurality of hosts 124, typically by 
means of a telephone line. Those of ordinary skill in the art 
will recognize that other types of host-to-gateway device 
access methods may be provided by a Telcos or ISP such as 
frame relay, leased lines, ATM (Asynchronous Transfer 
Mode), ADSL (Asymmetric Digital Subscriber Line) and the 
like. The gateway device 122 has the capability to process 
access requests being sent from the hosts. These access 
requests would include, but not be limited to, account logon 
requests, service authorization requests and connection 
requests. In a preferred embodiment, the gateway device 
implements the RADIUS protocol as the communication 
language between itself and other ISP network interfaces. 
The gateway device 122 receives the account logon access 
requests from the hosts 124 and the proxier 126 within the 
gateway device 122 correspondingly proxies these access 
requests to AAA server 128 for user authentication purposes. 

The AAA server 128 then compares attribute data found 
in the account logon access request packets against data 
found in the user profiles 130 of the AAA server's memory 
bank. If the data in the RADIUS access requests are found 
to match data in the AAA server 128 then access to the 
network can be granted. Additionally, the AAA server 128 
holds service profiles 132 within the memory bank. The user 
profiles 130 contain, among various data attributes, a listing 
of which services (private and public domains) a specified 
user is authorized to access. The service profiles 132, which 
are not user dependant, contain attribute date for a specific 
service domain. The gateway device 122 can query the AAA 
server 128 for a given user profile 130 and then within the 
processor 134 of the gateway device 122 assess the profile 
to determine which services the user has authorization to 
access. 

The gateway device 122 also encompasses an accounting 
request generator 136 which is capable of generating the 
accounting start and stop requests for various events which 
are triggered within the gateway device 122. Upon the 
gateway device 122 authenticating the user for account 
logon, the accounting request generator 136 will issue an 
account logon accounting start request packet and forward 
the packet to the accounter 138 located within the AAA 
server 128. Similarly, upon the gateway device 122 autho- 
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rizing the user to access a specific service, the accounting 
request generator 136 will, typically, issue a service account- 
ing start request and forward the packet to the accounter 138 
located within the AAA server 128. In the instance where the 
service already has a then-existing connection established by 5 
the host or any other host connecting through the gateway 
device 122, no need would exist to generate the service start 
request because such a request will already be existing 
within the accounter 138. Once the user establishes a PPP 
connection 140 to the desired service 142, the accounting 10 
request generator 136 will issue a PPP connection account- 
ing start request and forward the packet to the accounter 138 
located within the AAA server 128. 

The gateway device 122 will also rely on the accounting 
request generator 136 to issue the accounting stop requests 15 
upon certain triggering events occurring. When the user 
disconnects from a PPP connection, the accounting request 
generator 136 will issue a PPP connection accounting stop 
request packet and forward this packet to the accounter 138 
where it will be married with its corresponding start request 20 
for accounting purposes. While these packets will typically 
be generated due to a host-request disconnect command, it 
is also possible to generate the packets when a disconnect is 
prompted by other events outside the control of the user, 
such as, a lost-carrier, a lost-service or a session-timeout. 25 
When the user disconnects from a PPP connection the 
processor 134 within the gateway device 122 will determine 
if any additional connections remain to that particular ser- 
vice through that particular tunnel or routed connection. If 
no additional connections remain, then the accounting 30 
request generator 136 will issue a service accounting stop 
request packet and forward this packet to the accounter 138 
where it will be married with the corresponding stop request 
for subsequent accounting purposes. While these service 
stop request packets will typically be generated as a result of 35 
a host-request disconnect command, it is also possible to 
generate the packets when a disconnect is prompted by other 
events outside the control of the user, such as, a lost-carrier, 
a lost-service or a session-timeout. Finally, when the host 
initiates an account logoff, the accounting request generator 40 
136 will issue an account logoff accounting stop request 
packet and forward this to the accounter 138 where it will be 
married with the corresponding stop request for subsequent 
accounting purposes. While these packets will typically be 
generated due to a user-requested logoff command, it is also 45 
possible to generate the stop packets when a logoff is 
prompted by other events outside the control of the user, 
such as a session timeout. 

Additionally, it is within the inventive concept herein 
disclosed to provide back-up capacity to both the gateway 50 
device 122 and AAA server 128 to compensate for device 
failures or errors in transmission. A back-up gateway device 
144 allows for a safeguard should the primary gateway 
device 122 become temporarily inactive and fail to provide 
a means for generating and sending accounting start or stop 55 
requests, a secondary AAA server 146 allows for the initial 
accounting start request data to be catalogued in a second 
location should the primary AAA server encounter a tem- 
porary failure or service outage. 

In another preferred embodiment of the present invention, 60 
a computer network having the capabilities to use multiple- 
level accounting is illustrated in FIG. 4. A plurality of hosts 
150 have the capacity to gain network access through 
network access points 152. The access point is typically 
operated by a Telco or ISP and houses various network 65 
interfaces and service components. Included among these 
components are a plurality of gateway devices 154 and AAA 



servers 156. The AAA servers 156 may accommodate sev- 
eral client SSG's simultaneously and communicate with one 
another according to a standard Internet protocol, such as 
RADIUS. The gateway devices 154 are in communication 
with a plurality of hosts 150, typically by means of a 
telephone line. Those of ordinary skill in the art will 
recognize that other types of host-to-gateway device access 
methods may be provided by a Telcos or ISP such as frame 
relay, leased lines, ATM (Asynchronous Transfer Mode), 
ADSL (Asymmetric Digital Subscriber Line) and the like. 
The gateway devices 154 are capable of receiving account 
logon and service requests from the hosts 150, proxying 
these requests to the AAA servers 156 for authentication and 
authorization and then determining account logon and ser- 
vice. Once these determinations are made the gateway 
devices generates accounting start requests based on account 
logon, service establishment and PPP connection start. 
When the host initiates a termination request or when other 
events outside the control of the user dictate such, the 
gateway device generates accounting stop requests based on 
account logoff, service disconnect and PPP connection stop. 

Alternative Embodiments 

Although illustrative presently preferred embodiments 
and applications of this invention are shown and described 
herein, many variations and modifications are possible 
which remain within the concept, scope and spirit of the 
invention, and these variations would become clear to those 
skilled in the art after perusal of this application. The 
invention, therefore, is not limited except in spirit of the 
appended claims. 

What is claimed is: 

1. A method for providing multiple-level accounting to a 
computer network service provider comprising the steps of: 

generating an internet protocol account logon accounting 
start request in response to a determination that a 
subscriber has logged on to said computer network 
service provider; 

forwarding said internet protocol account logon start 
accounting request to a memory; 

generating an internet protocol service accounting start 
request in response to a determination that said sub- 
scriber has logged on to a service and that no other 
subscribers have a current connection established to 
said service through the computer network service 
provider interface; 

forwarding said internet protocol service accounting start 
request to a memory; 

generating an internet protocol service accounting stop 
request in response to a determination that said sub- 
scriber has terminated said service and that no other 
subscribers have a current connection established to 
said service through the computer network service 
provider interface; and 

forwarding said internet protocol service accounting stop 
request to a memory. 

2. The method of claim 1 further comprising the steps of: 
generating an internet protocol connection accounting 

start request in response to a determination that said 
subscriber has established a connection with said ser- 
vice; 

forwarding said internet protocol connection accounting 

start requests to a memory; 
generating an internet protocol connection accounting 

stop request in response to a determination that said 

subscriber has terminated said connection with said 

service; and 
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forwarding said internet protocol connection accounting 
stop requests to a memory. 

3. The method of claim 1 further comprising the steps of: 
generating an internet protocol account logoff accounting 

stop request in response to a determination that the 5 
subscriber has logged off said computer network ser- 
vice provider; and 
forwarding said internet protocol account logoff account- 
ing stop requests to a memory. 

4. The method of claim 1 further comprising the steps of: 10 
generating an internet protocol update accounting request 

at predetermined intervals after said internet protocol 
account logon accounting start request has been 
received into said memory; and 
forwarding said internet protocol update accounting 
requests to a memory. 

5. A method for providing multiple-level accounting to a 
computer network service provider comprising the steps of: 

receiving a user account logon access request at said 20 
computer network service provider; 

authorizing and authenticating said user in response to 
receiving said user account logon request; 

sending an account logon accounting start request to an 
accounting server; 25 

receiving a user service access request at said computer 
network service provider to access a requested service; 

granting user service privileges to said user if said 
requested service is contained within a service profile 
of said user; 30 

sending a service accounting start request to said account- 
ing server if said computer network service provider 
interface has not already established a service connec- 
tion with said requested service; and 

responsive to a determination that said user has discon- 35 
nected from said requested service, sending a service 
accounting stop request to said accounting server if no 
other hosts have current connections to said requested 
service. 

6. The method of claim 5 further comprising the steps of: 40 
establishing a connection between said user and said 

requested service after granting user service privileges 
to said user; 

sending a connection accounting start request to said 
accounting server; and 

responsive to a determination that said user has discon- 
nected from said requested service, sending a connec- 
tion accounting stop request to said accounting server. 

7. The method of claim 6 further comprising the steps of: 5Q 
responsive to a determination that said user has termi- 
nated said account logon, sending an account logoff 
accounting stop request to said accounting server. 

8. The method of claim 7 further comprising the step of: 
re-sending said account logoff accounting stop request at 55 

predetermined intervals upon determining that said 
initial connection accounting stop request was not 
received by said accounting server. 

9. The method of claim 6 further comprising the steps of: 
re-sending said connection accounting start request at 60 

predetermined intervals upon determining that said 
initial connection accounting start request was not 
received by said accounting server; and 
re-sending said connection accounting stop request at 
predetermined intervals upon determining that said 65 
initial connection accounting stop request was not 
received by said accounting server. 
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10. The method of claim 5 wherein the step of receiving 
a user account logon access request further comprises 
receiving said request directly from a dashboard application 
launched on said user's host computer. 

11. The method of claim 5 wherein the step of receiving 
a user account logon access request further comprises 
receiving said request from a remote web server. 

12. The method of claim 5 further comprising the steps of: 
generating update accounting requests at predetermined 

intervals after said account logon accounting start 
request has been received into said accounting server; 
and 

forwarding said internet protocol update accounting 
request to said accounting server. 

13. The method of claim 5 further comprising the steps of: 
re-sending said account logon accounting start request at 

predetermined intervals upon determining that said 
initial account logon accounting start request was not 
received by said accounting server; 

re-sending said service accounting start request at prede- 
termined intervals upon determining that said initial 
service accounting start request was not received by 
said accounting server; and 

re-sending said service accounting stop request at prede- 
termined intervals upon determining that said initial 
service accounting stop request was not received by 
said accounting server. 

14. An accounting metering apparatus for providing 
multiple-level accounting to a computer network service 
provider comprising the following: 

a means for receiving a user account logon access request 
at said computer network service provider; 

a means for authorizing and authenticating said user in 
response to receiving said user account logon request; 

a means for sending an account logon accounting start 
request to an accounting server; 

a means for receiving a user service access request at said 
computer network service provider to access a 
requested service; 

a means for granting user service privileges to said user if 
said requested service is contained within a service 
profile of said user; 

a means for sending a service accounting start request to 
said accounting server if said computer network service 
provider interface has not already established a service 
connection with said requested service; and 

a means for, responsive to a determination that said user 
has disconnected from said requested service, sending 
a service accounting stop request to said accounting 
server if no other hosts have current connections to said 
requested service. 

15. The accounting metering apparatus of claim 14 further 
comprising the following: 

a means for establishing a connection between said user 
and said requested service after granting user service 
privileges to said user; 

a means for sending a connection accounting start request 
to said accounting server; and 

a means for, responsive to a determination that said user 
has disconnected from said requested service, sending 
a connection accounting stop request to said accounting 
server. 

16. The accounting metering apparatus of claim 15 further 
comprising the following: 
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a means for, responsive to a determination that said user 
has terminated said account logon, sending an account 
logoff accounting stop request to said accounting 
server. 

17. An accounting metering system for providing 5 
multiple-level accounting to a network service provider 
within a computer network comprising the following: 
a gateway device capable of receiving network, service 
and connection access request packets from a plurality 
of hosts, said gateway device including: 10 
a proxier capable of readying logon authentication 
request packets and service authorization request 
packets for verification, 
a processor capable of granting network access, service 

establishment and connection access; 15 
an accounting request generator capable of generating 
accounting start request packets and accounting stop 
request packets for network account logons and 
logoffs, service establishments and terminations and 
connection accesses and terminations; 20 
an authentication, authorization and accounting server 
communicating with said gateway device by a net- 
work service provider proscribed internet protocol, 
said authentication, authorization and accounting 
server consisting of: 25 
an authenticator capable of verifying the authenticity 
of a user based on information contained in 
memory and comparable information found in 
said logon authentication request packets; 
a user specific service profile which contains a listing 30 
of the services which the user is authorized to 
access; and 
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an accounting tabulator capable of storing said 
accounting start requests and said accounting stop 
requests received from said gateway device. 

18. The accounting metering system of claim 17 wherein 
said internet protocol used as a communication means 
between said gateway device and said authentication, autho- 
rization and accounting server further comprises the 
RADIUS protocol. 

19. The accounting metering system of claim 17 wherein 
said accounting start requests and said accounting stop 
requests further comprise account attributes for both time 
and byte counts. 

20. The accounting system of claim 17 further compris- 
ing: 

a second gateway device capable of acting as a standby 
gateway device if the first gateway device fails or 
becomes temporarily non-functional. 

21. The accounting system of claim 17 further compris- 
ing: 

a second authentication, authorization and accounting 
device capable of acting as a standby authentication, 
authorization and accounting device if the first 
authentication, authorization and accounting device 
fails or becomes temporarily non-functional. 

22. The accounting system of claim 17 wherein said 
network, service and connection access request packets and 
said network, service and connection accounting request 
packets further comprise eight byte integer counters. 

* * * * * 
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Status of this Memo 



This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 

Copyright Notice 

Copyright (C) The Internet Society (2000) . All Rights Reserved. 

Abstract 

This document describes a protocol for carrying accounting 
information between a Network Access Server and a shared Accounting 
Server . 



Implementation Note 

This memo documents the RADIUS Accounting protocol . The early 
deployment of RADIUS Accounting was done using UDP port number 1646, 
which conflicts with the "sa-msg-port" service. The officially 
assigned port number for RADIUS Accounting is 1813. 
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1 . Introduction 



Managing dispersed serial line and modem pools for large numbers of 
users can create the need for significant administrative support. 
Since modem pools axe by definition a link to the outside world, they 
require careful attention to security, authorization and accounting. 
This can be best achieved by managing a single "database" of users, 
which allows for authentication (verifying user name and password) 'as 
well as configuration information detailing the type of service to 
deliver to the user (for example, SLIP, ppp, telnet, rlogin) . 

The RADIUS (Remote Authentication Dial In User Service) document [2] 
specifies t he RADIUS protocol used for Authentication and 
Authorization. This memo extends the use of the RADIUS protocol to 
cover delivery of acco unting information from the Network Access 
Server (ETAS) to a RADIUS , accounting server. 

This document obsoletes RFC 2139 [1] . A summary of the changes 
between this document and RFC 2139 is available in the "Change Log" 
appendix. 

Key features of RADIUS Accounting are: 
Client/Server Model 

A Network Access Server (NAS) operates as a client of the 
RADIUS accounting server. The client is responsible for 
passing user accounting information to a designated RADIUS 
accounting server . 
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The RADIUS accounting server is responsible for receiving the 
accounting recjuest and returning a response to the client 
indicating that it has successfully received the request. 

The RADIUS accounting server can act as a proxy client to 
other kinds of accounting servers . 

Network Security 

Transactions between the client and RADIUS accounting server 
are authenticated through the use of a shared secret, which is 
never sent over the network. 

Extensible Protocol 

All transactions are comprised of variable length Attribute - 
Length -Value 3 -tuples. New attribute values can be added 
without disturbing existing implementations of the protocol. 

1.1. Specification of Requirements 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD" , " SHOULD NOT" , "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [3] . These 
key words mean the same thing whether capitalized or not. 

1.2. Terminology 

This document uses the following terms : 

service The NAS provides a service to the dial -in user, such as PPP 
or Telnet. 

session Each service provided by the NAS to a dial -in user 

constitutes a session, with the beginning of the session 
defined as the point where service is first provided and 
the end of the session defined as the point where service 
is ended. A user may have multiple sessions in parallel or 
series if the NAS supports that, with each session 
generating a separate start and stop accounting record with 
its own Acct -Session- Id. 

silently discard 

This means the implementation discards the packet without 
further processing. The implementation SHOULD provide the 
capability of .logging the error, including the contents of 
the silently discarded packet, and SHOULD record the event 
in a statistics counter. 
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2 . Operation 

When a client is configured to use RADIUS Accounting , at the start of 
service delivery it will generate an Accounting Start packet 
describing the type of service being delivered and the user it is 
being delivered to, and will send that to the RADIUS Accounting 
server, which will send back an acknowledgement that the -packet has 
been r eceived. At the end of service delivery the client will 
generate an Accounting Stop packet describing the type of service 
that was delivered and optionally statistics such as elapsed time, 
input and output octets, or input and output packets. It will send 
that to the RADIUS Accounting server, which will send back an 
acknowledgement that the packet has been received. 

The Accounting -Request {whether for Start or Stop) is submitted to 
the RADIUS accounting server via the network. It is recommended that 
the client continue attempting to send the Accounting -Request packet 
until it receives an acknowledgement, using some form of backoff. If 
no response is returned within a length of time, the request is re- 
sent a number of times . The client can also forward reaueshs a-n 
alternate server or servers in the event that the primary server is 
down o r unreachable. An alternate server can be used either after a 
number of tries to the primary server fail, or in a round- robin 
fashion. Retry and fallback algorithms are the topic of current 
research and are not specified in detail in this document. 

The RADIUS accounting server MAY make requests of other servers in 
order to satisfy the request, in which case it acts as a client. 

If the RADIUS accounting server is unable to successfully record the 
accounting packet it MUST NOT send an Accounting -Response 
acknowledgment to the client. 

2.1. Proxy 

See the "RADIUS" RFC [2] for information on Proxy RADIUS. Proxy 
Accounting RADIUS works the same way, as illustrated by the following 
example. 



The NAS sends an accounting -request to the forwarding server. 

The forwarding server logs the accounting -request (if desired) , 
adds its Proxy- State (if desired) after any other Proxy- State 
attributes, updates the Request Authenticator , and forwards the 
request to the remote server. 
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3. The remote server logs the accounting - request (if desired), 
copies all Proxy- State attributes in order and unmodified from 
the request to the response packet, and sends the accounting- 
response to the forwarding server. 

4. The forwarding server strips the last Proxy-State (if it added 
one in step 2) , updates the Response Authenticator and sends 
the accounting -response to the NAS. 

A forwarding server MUST not modify existing Proxy- State or Class 
attributes present in the packet. 

A forwarding server may either perform its forwarding function in a 
pass through manner, where it sends retransmissions on as soon as it 
gets them, or it may take responsibility for retransmissions, for 
example in cases where the network link between forwarding and remote 
server has very different characteristics than the link between NAS 
and forwarding server. 

Extreme care should be used when implementing a proxy server that 
takes responsibility for retransmissions so that its retransmission 
policy is robust and scalable. 

3 . Packet Format 

Exactly one RADIUS Accounting packet is encapsulated in the UDP Data 
field [4] , where the UDP Destination Port field indicates 1813 
(decimal) . 

When a reply is generated, the source and destination ports are 
reversed. 

This memo documents the RADIUS Accounting protocol. The early 
deployment of RADIUS Accounting was done using UDP port number 1646, 
which conflicts with the "sa-msg-port" service. The officially 
assigned port number for RADIUS Accounting is 1813. 

A summary of the RADIUS data format is shown below. The fields are 
transmitted from left to right. 
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0 1 2 3 

01234567890123456789012345678901 

I Code | Identifier | Length | 

| I 
I Authenticator 1 



+-+-+-+-+-+-+-+. +-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+.+-+ 
I Attributes . . . 
+-+-+-+-+-+-+-+-+-+-+-+.+- 



Code 

The Code field is one octet, and identifies the type of RADIUS 
packet. When a packet is received with an invalid Code field, it 
is silently discarded. 



RADIUS Accounting Codes (decimal) are assigned as follows: 



4 Accounting - Request 

5 Ac conn t ing -Response 



Identifier 



The Identifier field is one octet, and aids in matching requests 
and replies. The RADIUS server can detect a duplicate request if 
it has the same client source IP address and source UDP port and 
Identifier within a short span of time. 

Length 



The Length field is two octets. It indicates the length of the 
packet including the Code, Identifier, Length, Authenticator and 
Attribute fields. Octets outside the range of the Length field 
MUST be treated as padding and ignored on reception. If the 
packet is shorter than the Length field indicates, it MUST be 
silently discarded. The minimum length is 20 and maximum length 
is 4095- 

Authenticator 

The Authenticator field is sixteen (16) octets. The most 
significant octet is transmitted first. This value is used to 
authenticate the messages between the client and RADIUS accounting 
server . 
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In Accounting -Request Packets, the Authenticator value is a 16 
octet MD5 [5] checksum, called the Request Authenticator • 

The NAS and RADIUS accounting server share a secret. The Request 
Authenticator field in Accounting -Request packets contains a one- 
way MD5 hash calculated over a stream of octets consisting of the 
Code + Identifier + Length + 16 zero octets + request attributes + 
shared secret (where + indicates concatenation) . The 16 octet MD5 
hash value is stored in the Authenticator field of the 
Accounting -Request packet . 

Note that the Request Authenticator of an Accounting -Request can 
not be done the same way as the Request Authenticator of a RADIUS 
Access -Request, because there is no User-Password attribute in an 
Accounting -Request . 

Response Authenticator 

The Authenticator field in an Accounting -Response packet is called 
the Response Authenticator, and contains a one-way MD5 hash 
calculated over a stream of octets consisting of the Accounting- 
Response Code, Identifier, Length, the Request Authenticator field 
from the Accounting -Request packet being replied to, and the 
response attributes if any, followed by the shared secret. The 
resulting 16 octet MD5 hash value is stored in the Authenticator 
field of the Accounting -Response packet . 

Attributes 

Attributes may have multiple instances, in such a case the order 
of attributes of the same type SHOULD be preserved. The order of 
attributes of different types is not required to be preserved. 

Packet Types 

The RADIUS packet type is determined by the Code field in the first 
octet of the packet. 
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4 . 1 . Accoun t ing - Reques t 
Description 

Accounting -Request packets are sent from a client {typically a 
Network Access Server or its proxy) to a RADIUS accounting server, 
and convey information used to provide accounting for a service 
provided to a user. The client transmits a RADIUS packet with the 
Code field set to 4 (Accounting -Request ) . 

Upon receipt of an Accounting -Request , the server MUST transmit an 
Account ing - Response reply if it successfully records the 
accounting packet, and MUST WOT transmit any reply if it fails to 
record the accounting packet. 

Any attribute valid in a RADIUS Access -Request or Access -Accept 
packet is valid in a RADIUS Accounting- Request packet, except that 
the following attributes MUST NOT be present in an Accounting- 
Request: User -Pas sword, CHAP - Pas sword , Reply -Message, State. 
Either NAS - IP - Address or NAS -Identifier MUST be present in a 
RADIUS Accounting -Request. It SHOULD contain a MAS -Port or NAS - 
Port -Type attribute or both unless the service does not involve a 
port or the NAS does not distinguish among its ports. 

If the Accounting -Request packet includes a Framed - IP - Address , 
that attribute MUST contain the IP address of the user. If the 
Access -Accept used the special values for Framed -IP -Address 
telling the NAS to assign or negotiate an IP address for the user, 
the Framed -IP -Address (if any) in the Account ing -Request MUST 
contain the actual IP address assigned or negotiated. 

A summary of the Accounting -Request packet format is shown below. 

The fields are transmitted from left to right. 



+ - + - + - + -+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + _ + _+_ + _ + _ + _ + _ + 



I Attributes ... 

4-- + - + - + - + - + - + - + - + -+-+-+-+- 




Request Authenticator 
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Code 



4 for Accounting -Request , 
Identifier 

The Identifier field MUST be changed whenever the content of the 
attributes field changes, and whenever a valid reply has been 
received for a previous request. For retransmissions where the 
contents are identical, the Identifier MUST remain unchanged. 

Note that if Acct -Delay -Time is included in the attributes of an 
Accounting -Request then the Acct -Delay-Time value will be updated 
when the packet is retransmitted, changing the content of the 
Attributes field and requiring a new Identifier and Request 
Authen t i ca t or . 

Request Authenticator 

The Request Authenticator of an Accounting -Request contains a 16-octet 
MD5 hash value calculated according to the method described in 
"Request Authenticator" above. 

Attributes 

The Attributes field is variable in length, and contains a list of 
Attributes . 

4.2. Account ing -Respons e 

Description 

Account ing -Response packets are sent by the RADIUS accounting 
server to the client to acknowledge that the Accounting -Request 
has been received and recorded successfully. If the Accounting- 
Request was recorded successfully then the RADIUS accounting 
server MUST transmit a packet with the Code field set to 5 
{Accounting -Response) . On reception of an Accounting -Response by 
the client, the Identifier field is matched with a pending 
Account ing -Request. The Response Authenticator field MUST contain 
the correct response for the pending Accounting -Request. Invalid 
packets are silently discarded. 

A RADIUS Accounting -Response is not required to have any 
attributes in it. 

A summary of the Accounting-Response packet format is shown below. 
The fields are transmitted from left to right. 
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0 1 2 3 

0123456789 0 1 23456789012345678901 

+ - + - + . + - + -+- + - + - + -h.- + - + - + - + - + -4.- + - + - + - + - + - + - + - + _ + . + . + . + . + . + „ + . + _ + 

I Code | Identifier | Length | 

' i 

I Response Authenticator I 

i 

+ - + -+- + -+- + - + - + - + - + -+- + - + - + - + . + - + . + - + - + . + - + - + . + . + _ + . + . + . + . + . + . + _ + 

| Attributes . . . 
+-+-+-+-+-+-+-+-+-+.+.+.+_ 

Code 

5 for Accounting -Response. 
Identifier 

The Identifier field is a copy of the Identifier field of the 
Accounting-Request which caused this Accounting -Response. 

Response Authenticator 

The Response Authenticator of an Accounting -Response contains a 
16 -octet MD5 hash value calculated according to the method 
described in "Response Authenticator" above. 

Attributes 

The Attributes field is variable in length, and contains a list of 
zero or more Attributes* 

5 . Attributes 

RADIUS Attr ibutes carry the specific authentication, authorization 
and accounting details for the request and response. 

Some attributes MAY be included more than once. The effect of this 
is attribute specific, and is specified in each attribute 
description. 

The end of the list of attributes is indicated by the Length of the 
RADIUS packet. 

A summary of the attribute format is shown below. The fields are 
transmitted from left to right. 
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0 12 
012345678901234567890123 

I Type | Length | Value . . . 



Type 

The Type field is one octet. Up-to-date values of the RADIUS Type 
field are specified in the most recent "Assigned Numbers" RFC [6] . 
Values 192-223 are reserved for experimental use, values 224-240 
are reserved for implementation- specif ic use, and values 241-255 
are reserved and should not be used- This specification concerns 
the following values : 



1-39 


{refer to RADIUS document 


[2] ) 


40 


Acct - Status - Type 




41 


Acc t - Delay - Time 




42 


Acct - Input - Octets 




43 


Acct -Output -Octets 




44 


Acct - Session - Id 




45 


Acct - Authentic 




46 


Acct - Ses sion - Time 




47 


Acct - Input - Packets 




48 


Acct - Output - Packets 




49 


Acct - Terminate - Cause 




50 


Acct -Multi - Session-Id 




51 


Acct - Link- Count 




60+ 


(refer to RADIUS document 


[2] ) 



Length 

The Length field is one octet, and indicates the length of this 
attribute including the Type, Length and Value fields. If an 
attribute is received in an Accounting-Request with an invalid 
Length, the entire request MUST be silently discarded. 

Value 

The Value field is zero or more octets and contains information 
specific to the attribute. The format and length of the Value 
field is determined by the Type and Length fields . 

Note that none of the types in RADIUS terminate with a NUL (hex 
00). In particular, types "text" and "string" in RADIUS do not 
terminate with a NUL {hex 00) . The Attribute has a length field 
and does not use a terminator. Text contains UTF-8 encoded 10646 
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[7] characters and String contains 8 -bit binary data. Servers and 
servers and clients MUST be able to deal with embedded nulls. 
RADIUS implementers using C are cautioned not to use strcpyO when 
handling strings. 

The format of the value field is one of five data types - Note 
that type "text" is a subset of type "string. 11 



text 1-253 octets containing UTF-8 encoded 10646 [7] 

characters. Text of length zero (0) MUST NOT be sent; 
omit the entire attribute instead. 

string 1-253 octets containing binary data (values 0 through 255 
decimal, inclusive) . Strings of length zero (0) MUST NOT 
be sent; omit the entire attribute instead. 

address 32 bit value, most significant octet first. 



integer 32 bit unsigned value, most significant octet first, 



time 



32 bit unsigned value, most significant octet first - - 
seconds since 00:00:00 UTC, January 1, 197 0, The 
standard Attributes do not use this data type but it is 
presented here for possible use in future attributes. 



5.1. Acct- Status -Type 



Description 



This attribute indicates whether this Accounting -Request marks the 
beginning of the user service (Start) or the end (Stop) . 

It MAY be used by the client to mark the start of accounting (for 
example, upon booting) by specifying Accounting -On and to mark the 
end of accounting (for example, just before a scheduled reboot) by 
specifying Accounting -Off . 

A summary of the Acct- Status -Type attribute format is shown below. 
The fields are transmitted from left to right. 

0-1 2 3 

01234567890123456789012345678901 

I Type | Length | Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

Value (cont) | 
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + -+- + 
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Type 

4 0 for Acct -Status -Type. 
Length 
6 

Value 

The Value field is four octets. 



1 Start 

2 Stop 

3 Interim -Update 

7 Accounting -On 

8 Accounting- Off 

9-14 Reserved for Tunnel Accounting 

15 Reserved for Failed 



5.2. Acct -Delay-Time 
Description 

This attribute indicates how many seconds the client has been 
trying to send this record for, and can be subtracted from the 
time of arrival on the server to find the approximate time of the 
event generating this Accounting -Request . (Network transit time 
is ignored.) 

Note that changing the Acct -Delay- Time causes the Identifier to 
change; see the discussion under Identifier above. 

A summary of the Acct -Delay -Time attribute format is shown below. 
The fields are transmitted from left to right. 

0 12 3 

012 34567890123456789012345678901 

+ - + - + - + + h-H 1 I i h-H h-H \ ! \ h - 4- - H h - + - H I I h 

I Type | Length | Value 

Value (cont) | 
+ - + - + - + - + - + - + - + - + - + - + - + - + -+- + - + - + 
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Type 

41 for Acct -Delay -Time. 
Length 

6 

Value 

The Value field is four octets. 
5.3. Acct - Input - Octets 
Description 

This attribute indicates how many octets have been received from 
the port over the course of this service being provided, and can 
only be present in Accounting-Request records where the Acct- 
Status-Type is set to Stop. 

A summary of the Acct -Input -Octets attribute format is shown below. 
The fields are transmitted from left to right. 

0 12 3 

01234567890123456789012345678901 

I Type | Length | Value 

Value (cont) | 
+ - + - + - + - + - + - + - + - + - + - + - + -+- + - + -+- + 

Type 

42 for Acct -Input -Octets . 
Length 

6 

Value 

The Value field is four octets. 
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5.4. Acct -Output -Octets 
Description 

This attribute indicates how many octets have been sent to the 
port in the course of delivering this service, and can only be 
present in Accounting-Request records where the Acct - Status - Type 
is set to Stop. 

A summary of the Acct -Output -Octets attribute format is shown below. 
The fields are transmitted from left to right . 

0 1 2 3 

01234567890123456789012345678901 

I Type | Length | Value 

Value (cont) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type 

43 for Acct -Output- Octets . 
Length 
6 

Value 

The Value field is four octets. 
5.5* Acct -Session- Id 
Description 

This attribute is a unique Accounting ID to make it easy to match 
start and stop records in a log file. The start and stop records 
for a given session MUST have the same Acct-Session-Id. An 
Accounting -Request packet MUST have an Acct-Session-Id. An 
Access -Request packet MAY have an Acct-Session-Id; if it does, 
then the NAS MUST use the same Acct-Session-Id in the Accounting - 
Request packets for that session. 

The Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7] 
characters . 
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For example, one implementation uses a string with an 8 -digit 
upper case hexadecimal number, the first two digits increment on 
each reboot (wrapping every 256 reboots) and the next 6 digits 
counting from 0 for the first person logging in after a reboot up 
to 2*24-1, about 16 million. Other encodings are possible. 

A summary of the Acct- Session- Id attribute format is shown below. 
The fields are transmitted from left to right. 

0 i 2 

012345678901234567890123 
+ - + -+- + -+- + - + - + -+- + - + - + - + - + . + - + - + . + . + . + . + . + - + _ + . + 

I Type | Length | Text . . . 

+ -+- + - + -+- + - + . + -+-+-+- + - + - + -4- + - + - + - + - + - + - + - + - + 

Type 

44 for Acct-Session-Id. 
Length 

>= 3 
String 

The String field SHOULD be a string of UTF-8 encoded 10646 [7] 
characters . 

5.6. Acct -Authentic 

Description 

This attribute MAY be included in an Accounting -Request to 
indicate how the user was authenticated, whether by RADIUS, the 
NAS itself, or another remote authentication protocol. Users who 
are delivered service without being authenticated SHOULD NOT 
generate Accounting records. 

A summary of the Acct -Authentic attribute format is shown below. The 
fields are transmitted from left to right. 

0 1 2 3 

01234567890123456789012345678901 

I Type | Length | Value 

+ - + - + - + - + - + - +- + - + -+- + - + .••+- + - + -+- + -+- + . + . + - + . + - + - + . + . + . + _ + . + . + . + . + 

Value (cont) | 
+ - + - + - + - + - + - + -+- + - + - + - + - + - + - + - + - + 
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Type 

45 for Acct -Authentic . 
Length 

6 

Value 

The Value field is four octets. 

1 RADIUS 

2 Local 

3 Remote 

5 . 7 . Acct - Ses s ion - Time 
Description 

This attribute indicates how many seconds the user has received 
service for, and can only be present in Accounting -Recjuest records 
where the Acct- Status -Type is set to Stop. 

A summary of the Acct -Session -Time attribute format is shown below. 
The fields are transmitted from left to right . 

0 12 3 

01234567890123456789012345678901 

+ - + - + - + - + - + - + 1 1 1 1 1 1 1 1 1 1 i 1 J 1 1 1 1 1 1 1 i ! 1 1 h 

| Type | Length | Value 

Value (cont) | 
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 

Type 

46 for Acct - Session -Time. 
Length 

6 

Value 

The Value field is four octets - 
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5.8. Acct - Input - Packets 
Description 

This attribute indicates how many packets have been received from 
the port over the course of this service being provided to a 
Framed User, and can only be present in Accounting -Request records 
where the Acct -Status -Type is set to Stop. 

A summary of the Acct -Input -packets attribute format is shown below. 
The fields are transmitted from left to right. 

0l2 3 
01234567890123456789 0123456789 0 1 

I Type | Length | Value 

Value (cont) | 
+ - + -+-+-+- + - + -+- + . + _ + . 4.. + .. + . + _ + .. + 

Type 

47 for Acct -Input- Packets . 
Length 
6 

Value 

The Value field is four octets. 

5.9. Acct -Output -Packets 
Description 

This attribute indicates how many packets have been sent to the 
port in the course of delivering this service to a Framed User, 
and can only be present in Accounting -Request records where the 
Acct -Status -Type is set to Stop. 

A summary of the Acct -Output -Packets attribute format is shown below. 
The fields are transmitted from left to right. 



Rigney 



Informa t i ona 1 



[Page 18] 



RFC 2 866 RADIUS Accounting June 200 0 



0 12 3 

01234567890123456789012345678901 

I Type | Length | Value 

Value (cont) | 

+ -+- + - + -+ -H-- + -H 1 J-- + -4-- + - + -4--+- + 

Type 

4 8 for Acct -Output- Packets . 
Length 
6 

Value 

The Value field is four octets. 
5 , 10 . Acct -Terminate -Cause 
Description 

This attribute indicates how the session was terminated, and can 
only be present in Accounting -Request records where the Acct- 
Status-Type is set to Stop. 

A summary of the Acct -Terminate -Cause attribute format is shown 
below. The fields are transmitted from left to right. 

0 12 3 

01234567890123456789012345678901 

I Type | Length . | Value 

Value (cont) | 
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 
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Type 

49 for Acct- Terminate -Cause 
Length 
6 

Value 

The Value field is four octets, containing an integer specifying 
the cause of session termination, as follows: 

1 User Request 

2 Lost Carrier 

3 Lost Service 

4 Idle Timeout 

5 Session Timeout 

6 Admin Reset 

7 Admin Reboot 

8 Port Error 

9 NAS Error 

10 NAS Request 

11 HAS Reboot 

12 Port Unneeded 

13 Port Preempted 

14 Port Suspended 

15 Service Unavailable 

16 Callback 

17 User Error 

18 Host Request 

The termination causes are as follows: 

User Request User requested termination of service, for 

example with LCP Terminate or by logging out . 

Lost Carrier DCD was dropped on the port. 

Lost Service Service can no longer be provided; for 

example, user's connection to a host was 
interrupted. 

Idle Timeout Idle timer expired. 

Session Timeout Maximum session length timer expired. 

Admin Reset Administrator reset the port or session. 
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Admin Reboot 
Port Error 
NAS Error 
NAS Request 
NAS Reboot 
Port Unneeded 

Port Preempted 
Port Suspended 



Administrator is ending service on the NAS, 
for example prior to rebooting the NAS . 

NAS detected an error on the port which 
required ending the session. 

NAS detected some error (other than on the 
port) which required ending the session. 

NAS ended session for a non-error reason not 
otherwise listed here. 

The NAS ended the session in order to reboot 
non -administratively ("crash") . 

NAS ended session because resource usage fell 
below low- water mark (for example, if a 
bandwidth -on -demand algorithm decided that 
the port was no longer needed) . 

NAS ended session in order to allocate the 
port to a higher priority use. 

NAS ended session to suspend a virtual 
session. 



Service Unavailable NAS was unable to provide requested service. 
Callback 



User Error 



NAS is terminating current session in order 
to perform callback for a new session. 

Input from user is in error, causing 
termination of session. 



Host Request Login Host terminated session normally. 

5.11. Acct-Multi- Session- Id 
Description 

This attribute is a unique Accounting ID to make it easy to link 
together multiple related sessions in a log file. Each session 
linked together would have a unique Acct - Session- Id but the same 
Acct-Multi -Session- Id. It is strongly recommended that the Acct- 
Multi - Session-Id contain UTF-8 encoded 10646 [7] characters. 

A summary of the Acct -Session- Id attribute format is shown below. 
The fields are transmitted from left to right. 
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0 12 
012345678901234567890123 

I Type | Length | String . . . 

+ - + - + - + - + - + -+-+- + - + - + - + - + - + -+- + - + - + - + -+-+- + - + -+- + 

Type 

50 for Acct -Multi -Session- Id - 

Length 

>= 3 

String 

The String field SHOULD contain UTF-8 encoded 10646 [7] characters. 
5.12. Acct -Link -Count 
Description 

This attribute gives the count of links which are known to have been 
in a given multilink session at the time the accounting record is 
generated. The NAS MAY include the Acct -Link -Count attribute in any 
Accounting-Request which might have multiple links. 

A summary of the Acct - Link - Count attribute format is show below. The 
fields are transmitted from left to right . 

0 12 3 

01234567890123456789012345678901 

I Type | Length | Value 

Value (cont) | 
+ - + - + + - + + -4-- + - + - + - + - + - + 
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Type 



51 for Acct -Link- Count . 



Length 



6 

Value 



The Value field is four octets, and contains the number of links 
seen so far in this Multilink Session. 

It may be used to make it easier for an accounting server to know 
when it has all the records for a given Multilink session. When 
the number of Accounting -Requests received with Acct - Status -Type = 
Stop and the same Acct -Multi -Session-Id and -unique Acct-Session- 
Id's equals the largest value of Acct -Link -Count seen in those 
Accounting -Requests , all Stop Accounting -Requests for that 
Multilink Session have been received. 

An example showing 8 Accounting-Requests should make things 
clearer. For clarity only the relevant attributes are shown, but 
additional attributes containing accounting information will also 
be present in the Accounting - Reques t . 



Mul ti - Session- Id 


Session-Id 


Status -Type 


Link 


"10" 


"10" 


Start 


1 


"10" 


"ll" 


Start 


2 


"10" 


"11« 


Stop 


2 


"10" 


"12" 


Start 


3 


"10" 


"13" 


Start 


4 


»10» 


"12" 


Stop 


4 


»10» 


"13" 


Stop 


4 


"10" 


»io» 


Stop 


4 



5.13. Table of Attributes 



The following table provides a guide to which attributes may be found 
in Accounting -Request packets. Wo attributes should be found in 
Accounting -Response packets except Proxy-State and possibly Vendor- 
Specific. 



# Attribute 

0-1 . User -Name 

0 User -Password 

0 CHAP -Password 
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0-1 MAS -IP -Address [Note 1] 

0-1 NAS - Port 

0-1 Service-Type 

0-1 Framed - Protocol 

0-1 Framed - IP - Addres s 

0-1 Framed- IP -Netmask 

0-1 Framed -Routing 

0+ Filter-Id 

0-1 Framed -MTU 

0 + Framed - Compres s ion 

0+ Login- IP-Host 

0-1 Login- Service 

0-1 Login - TCP - Port 

0 Reply -Mess age 

0 - 1 Cal Iback - Number 

0-1 Callback- Id 

0 + Framed - Route 

0-1 Framed - IPX -Network 

0 State 
0+ Class 

0+ Vendor -Specific 

0-1 Session -Timeout 

0-1 Idle -Timeout 

0-1 Termination -Action 

0-1 Called- Station- Id 

0-1 Calling- Station- Id 

0-1 NAS- Identifier [Note 1] 

0+ Proxy- State 

0-1 Login- LAT- Service 

0-1 Login - LAT - Node 

0-1 Login - LAT - Group 

0-1 Framed - AppleTalk - Link 

0-1 Framed - Appl eTalk - Network 

0-1 Framed - AppleTalk- Zone 

1 Acct- Status -Type 
0-1 Acct - Delay - Time 
0-1 Acct - Input - Octets 
0-1 Acct - Output - Octets 
1 Acct- Session-Id 
0-1 Acct -Authentic 

0-1 Acct - Session -Time 

0-1 Acct - Input - Packets 

0-1 Acct - Output - Packets 

0-1 Acct -Terminate -Cause 

0+ Acct -Multi - Session- Id 

0+ Acct -Link -Count 

0 CHAP -Challenge 
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0-1 NAS - Port - Type 
0-1 Port -Limit 
0-1 Login - LAT - Port 

[Note 1] An Accounting - Regies t MUST contain either a NAS -IP -Address 
or a NAS -Identifier (or both) . 

The following table defines the above table entries, 

0 This attribute MUST NOT be present 

0+ zero or more instances of this attribute MAY be present. 
0-1 Zero or one instance of this attribute MAY be present. 

1 Exactly one instance of this attribute MUST be present. 

6 . IANA Considerations 

The Packet Type Codes, Attribute Types, and Attribute Values defined 
in this document are registered by the Internet Assigned Numbers 
Authority (IANA) from the RADIUS name spaces as described in the 
"IANA Considerations" section of RFC 2865 [2] , in accordance with BCP 
26 [8] - 

7 . Security Considerations 

Security issues are discussed in sections concerning the 
authenticator included in accounting requests and responses, using a 
shared secret which is never sent over the network. 

8 . Change Log 

US-ASCII replaced by UTF-8. 
Added notes on Proxy. 

Framed- IP -Address should contain the actual IP address of the user. 

If Acct- Session -ID was sent in an access -request, it must be used in 
the accounting -request for that session. 

New values added to Acct -Status -Type. 

Added an IANA Considerations section. 

Updated references. 

Text strings identified as a subset of string, to clarify use of 
UTF - 8 . 
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This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
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INTERNET ACCOUNTING : BACKGROUND 



Status of this Memo 



This memo provides information for the Internet community. It does 
not specify an Internet standard. Distribution of this memo is 
unlimited. 



1 . Statement of Purpose 

This document provides background information for the "Internet 
Accounting Architecture" and is the first of a three document set: 

Internet Accounting Background & Status (this document) 
Internet Accounting Architecture (under construction) 

Internet Accounting Meter Service (under construction) 

The focus at this time is on defining METER SERVICES and USAGE 
REPORTING which provide basic semantics for measuring network 
utilization, a syntax, and a data reporting protocol. The intent is 
to produce a set of standards that is of practical use for early 
experimentation with usage reporting as an internet accounting 
mechanism. 

The architecture should be expandable as additional experience is 
gained. The short-term Internet Accounting solution is intended to 
merge with OSI and Autonomous Network Research Group (ANRG) efforts 
and be superseded by those efforts in the long term. The OSI 
accounting working groups are currently defining meter syntax and 
reporting protocols . The ANRG research group is currently 
researching economic models and accounting tools for the Internet 
environment . 



Internet Accounting as described here does not wrestle with the 
applications of usage reporting, such as monitoring and enforcing 
network policy; nor does it recommend approaches to billing or tackle 
such thorny issues as who pays for packet retransmission. 

This document provides background and tutorial information on issues 
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surrounding the architecture, or in a sense, an explanation of 
choices made in the Internet Accounting Architecture . 

2 . Goals for a Usage Reporting Architecture 

We have adopted the accounting framework and terminology used by OSI 
(ISO 7498-4 OSI Reference Model Part 4: Management Framework) . This 
framework defines a generalized accounting management activity which 
includes calculations, usage reporting to users and providers and 
enforcing various limits on the use of resources. Our own ambitions 
are considerably more modest in that we are defining an architecture 
to be used over the short- term (until ISO and ANRG have final 
pronouncement and standards) that is limited to network USAGE 
REPORTING . 

The OSI accounting model defines three basic entities: 

1) the METER, which performs measurements and aggregates the 
results of those measurements; 

2) the COLLECTOR , which is responsible for the integrity and 
security of METER data in short-term storage and transit; 
and 

3) the APPLICATION, which processes/formats/stores METER 
data. APPLICATIONS implicitly manage METERS . 

This working group, then, is concerned with specifying the attributes 
of METERS and COLLECTORS, with little concern at this time for 
APPLICATIONS. 

3 . The Usage Reporting Function 
3.1. Motivation for Usage Reporting 

The dominant motivations for usage reporting are: 

o Understanding/ Influencing Behavior. 

Usage reporting provides feedback for the subscriber on 
his use of network resources . The subscriber can better 
understand his network behavior and measure the impact of 
modifications made to improve performance or reduce 
costs . 

o Measuring Policy Compliance. 

From the perspective of the network provider, usage 
reports might show whether or not a subscriber is in 
compliance with the stated policies for quantity of 
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network usage. Reporting alone is not sufficient to 
enforce compliance with policies, but reports can 
indicate whether it is necessary to develop additional 
methods of enforcement. 

o Rational Cost Allocation/Recovery. 

Economic discipline can be used to penalize inefficient 
network configuration/utilization as well as to reward 
the efficient. It can be used to encourage bulk transfer 
at off hours. It can be used as a means to allocate 
operating costs in a zero-sum budget, and even be used as 
the basis for billing in a profit-making fee-for-service 
operation . 



The chief deterrent to usage reporting is the cost of measuring 
usage, which includes: 



o Reporting/collection overhead. 

This offers an additional source of computational load 
and network traffic due to the counting operations, 
managing the reporting system, collecting the reported 
data, and storing the resulting counts. Overhead 
increases with the accuracy and reliability of the 
accounting data. 

o Post -processing overhead. 

Resources are required to maintain the post-processing 
tasks of maintaining the accounting database, generating 
reports, and, if appropriate, distributing bills, 
collecting revenue, servicing subscribers. 

o Security overhead. 

The use of security mechanisms will increase the overall 
cost of accounting. Since accounting collects detailed 
information about subscriber behavior on the network and 
since these counts may also represent a flow of money, it 
is necessary to have mechanisms to protect accounting 
information from unauthorized disclosure or manipulation. 



The balance between cost and benefit is regulated by the GRANULAR I T Y 
of accounting information collected. This balance is policy- 
dependent. To minimize costs and maximize benefit, accounting detail 
is limited to the minimum amount to provide the necessary information 
for the research and implementation of a particular policy. 
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3.2. Network Policy and Usage Reporting 

Accounting requirements are driven by policy. Conversely, policy is 
typically influenced by the available management /reporting tools and 
their cost . This section is NOT a recommendation for billing 
practices, but intended to provide additional background for 
understanding the problems involved in implementing a simple, 
adequate usage reporting system. 

Since there are few tools adequate for any form of cost recovery 
and/or long-term monitoring there are few organizations that practice 
proactive usage reporting in the Internet . Those that do have 
generally invented their own. But far and away the most common 
approach is to treat the cost of network operations as overhead with 
network reports limited to short-term, diagnostic intervention. But 
as the population and use of the Internet increases and diversifies, 
the complexity of paying for that usage also increases. Subsidies 
and funding mechanisms appropriate to non-profit organizations often 
restrict commercial use or require that "for profit" use be 
identified and billed separately from the non-profit use. Tax 
regulations may require verification of network connection or usage. 
Some portions of the Internet are distinctly "private", whereas other 
Internet segments are treated as public, shared infrastructure. 

The number of administrations operating in some connection with the 
Internet is exploding. The network "hierarchy" (backbone, regional, 
enterprise, stub network) is becoming deeper (more levels) , 
increasingly enmeshed (more cross-connections) and more diversified 
(different charters and usage patterns) . Each of these 
administrations has different policies and by-laws about who may use 
an individual network, who pays for it, and how the payment is 
determined. Also, each administration balances the OVERHEAD costs of 
accounting (metering, reporting, billing, collecting) against the 
benefits of identifying usage and allocating costs. 

Some members of the Internet community are concerned that the 
introduction of usage reporting will encourage new billing policies 
which are detrimental to the current Internet infrastructure (though 
it is also reasonable to assert that the current lack of usage 
reporting may be detrimental as well) . Caution and experimentation 
must be the watch words as usage reporting is introduced. Well 
before meters are^'used for active BILLING and ENFORCEMENT, they 
should first be used to: 

o UNDERSTAND USER BEHAVIOR 

(learn to quantify and/or predict individual and 
aggregate traffic patterns over the long term) , 
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o QUANTIFY NETWORK IMPROVEMENTS , 

(measure user and vendor efficiency in how network 
resources are consumed to provide end-user data transport 
service) and 

o MEASURE COMPLIANCE WITH POLICY. 

Accounting policies for network traffic already exist. But they are 
usually based on network parameters which change seldom, if at all. 
Such parameters require little monitoring (the line speed of a 
physical connection, e . g Ethernet , 9600 baud, FDDI ) . The connection 
to the network is then charged to the subscriber as a FLAT- FEE 
regardless of the amount of traffic passed across the connection and 
is similar to the monthly unlimited local service phone bill. 

Usage- insensitive access charges are sufficient in many cases, and 
can be preferable to usage-based charging in Internet environments, 
for financial, technical, and social reasons. Sample incentives for 
the FLAT-FEE billing approach are: 

O FINANCIAL: 

Predictable monthly charges. No overhead costs for 
counting packets and preparing usage-based reports. 

O TECHNICAL: 

Easing the sharing of resources. Eliminating the 
headaches of needing another layer of accounting in proxy 
servers which associate their usage with their clients' . 
Examples of proxy servers which generate network traffic 
on behalf of the actual user or subscriber are mail 
daemons, network file servers, and print spoolers. 

o SOCIAL: 

Treating the network as an unregulated public 
infrastructure with equal access and information sharing. 
Encouraging public -spirited behavior contributing to 
public mailing lists, information distribution, etc. 

In other cases USAGE -SENSITIVE charges may be preferred or required 
by a local administration's policy. Government regulations or the 
wishes of subscribers with low or intermittent traffic patterns may 
force the issue (note: FLAT FEES are beneficial for heavy network 
users. USAGE SENSITVE charges generally benefit the low-volume 
user) . Where usage-sensitive accounting is used, cost ceilings and 
floors may still be established by static parameters, such as "pipe 
size" for fixed connections or "connection time" for dial-up 
connection, to satisfy the need for some predictability. 
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Different billing schemes may be employed depending on network 
measures of distance. For example, local network traffic may be 
flat-rate and remote internet traffic may be usage-based, analogous 
to the local and long distance billing policies adopted by the 
telephone companies . 

The ANRG is independently investigating policy models and 
infrastructure economics for billing and cost recovery. 

3.3. The Nature of Usage Accounting 

Although the exact requirements for internet usage accounting will 
vary from one network administration to the next and will depend on 
policies and cost trade-offs, it is possible to characterize the 
problem in some broad terms and thereby bound it. Rather than try to 
solve the problem in exhaustive generality (providing for every 
imaginable set of accounting requirements), some assumptions about 
usage accounting are posited in order to make the problem tractable 
and to render implementations feasible. Since these assumptions form 
the basis for our architectural and design work, it is important to 
make them explicit from the outset and hold them up to the scrutiny 
of the Internet community. 

3.3.1. A Model for Internet Accounting 

We begin with the assumption that there is a "network administrator" 
or "network administration" to whom internet accounting is of 
interest. He "owns" and operates some subset of the internet (one or 
more connected networks) that may be called his "administrative 
domain". This administrative domain has well defined boundaries. 

our domain X 



/ I I I I 

/ I c 
/ / 

Network A / | \ * / 

(diagonals \ / 

II | cross admin. domain B 

boundaries) 

The network administrator is interested in 1) traffic within his 
boundaries and 2) traffic crossing his boundaries. Within his 
boundaries he may be interested in end- system to end -system 
accounting or accounting at coarser granularities (e.g., department 
to department) . 
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The network administrator is usually not interested in accounting for 
end- systems outside his administrative domain; his primary concern is 
accounting to the level of other ADJACENT (directly connected) 
administrative domains. Consider the viewpoint of the administrator 
for domain X of the internet. The idea is that he will send each 
adjacent administrative domain a bill (or other statement of 
accounting) for its use of his resources and it will send him a bill 
for his use of its resources. When he receives an aggregate bill 
from Network A, if he wishes to allocate the charges to end users or 
subsystems within his domain, it is HIS responsibility to collect 
accounting data about how they used the resources of Network A. If 
the "user" is in fact another administrative domain, B, (on whose 
behalf X was using A' s resources) the administrator for X just sends 
his counterpart in B a bill for the part of X's bill attributable to 
B's usage. If B was passing traffic for C, them B bills C for the 
appropriate portion X's charges, and so on, until the charges 
percolate back to the original end user, say G. Thus, the 
administrator for X does not have to account for G's usage; he only 
has to account for the usage of the administrative domains directly 
adjacent to himself. 

This paradigm of recursive accounting may, of course, be used WITHIN 
an administrative domain that is (logically) comprised of sub- 
administrative domains . 

The discussion of the preceding paragraphs applies to a general mesh 
topology, in which any Internet constituent domain may act as a 
service provider for any connected domain. Although the Internet 
topology is in fact such a mesh, there is a general hierarchy to its 
structure and hierarchical routing (when implemented) will make it 
logically hierarchical as far as traffic flow is concerned. This 
logical hierarchy permits a simplification of the usage accounting 
perspective . 

At the bottom of the service hierarchy a service- consuming host sits 
on one of many "stub" networks. These are interconnected into an 
enterprise -wide extended LAN, which in turn receives Internet 
service, typically from a single attachment to a regional backbone. 
Regional backbones receive national transport services from national 
backbones such as NSFnet , Alternet, PSInet, CERFnet, NSInet, or 
Nordunet . In this scheme each level in the hierarchy has a 
constituency, a group for which usage reporting is germane, in the 
level underneath it . In the case of the NSFnet the natural 
constituency, for accounting purposes at least, is the regional nets 
(MIDnet, SURAnet, ...) . For the regionals it will be their member 
institutions; for the institutions, their stub networks; and for the 
stubs, their individual hosts. 



Mills, Hirsh, & Ruth [Page 7] 





RFC 1272 



Internet Accounting: Background 



November 1991 



3.3.2. Implications of the Model 

The significance of the model sketched above is that Internet 
accounting must be able to support accounting for adjacent 
(intermediate) systems, as well as end-system accounting. Adjacent 
system accounting information cannot be derived from end- system 
accounting (even if complete end-system accounting were feasible) 
because traffic from an end-system may reach the administrative 
domain of interest through different adjacent domains, and it is the 
adjacent domain through which it passes that is of interest. 

The need to support accounting for adjacent intermediate systems 

means that internet accounting will require information not present 

in internet protocol headers (these headers contain source and 

destination addresses of end- systems only) . This information may 

come from lower layer protocols (network or link layer) or from 
configuration information for boundary components (e.g., "what syster 
is connected to port 5 of this IP router") . 



A METER is a process which examines a stream of packets on a 
communications medium or between a pair of media. The meter records 
aggregate counts of packets belonging to FLOWs between communicating 
entities (hosts/processes or aggregations of communicating hosts 
(domains)). The assignment of packets to flows may be done by 
executing a series of rules. Meters can reasonably be implemented in 
any of three environments dedicated monitors, in routers or in 
general -purpose systems. 

Meter location is a critical decision in internet accounting. An 
important criterion for selecting meter location is cost, i.e., 
REDUCING ACCOUNTING OVERHEAD and MINIMIZING THE COST OF 
IMPLEMENTATION. 

In the trade-off between overhead (cost of accounting) and detail, 
ACCURACY and RELIABILITY play a decisive role. Full accuracy and 
reliability for accounting purposes require that EVERY packet must be 
examined. However, if the requirement for accuracy and reliability 
is relaxed, statistical sampling may be more practical and 
sufficiently accurate, and DETAILED ACCOUNTING is not required at 
all. Accuracy and reliability requirements may be less stringent 
when the purpose of us age -reporting is solely to understand network 
behavior, for network design and performance tuning / or when usage 
reporting is used to approximate cost allocations to users as a 
percentage of total fees. 

Overhead costs are minimized by accounting at the coarsest acceptable 



4 . 



Meters 
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GRANULARITY, i.e., using the greatest amount of AGGREGATION possible 
no limit the number of accounting records generated, their size, and 
the frequency with which they are transmitted across the network or 
otherwise stored. 

The other cost factor lies in implementation. Implementation will 
necessitate the development and introduction of hardware and software 
components into the internet. It is important to design an 
architecture that tends to minimize the cost of these new components. 

4.1. Meter Placement 

In the model developed above, the Internet may be viewed as a 
hierarchical system of service providers and their corresponding 
constituencies. In this scheme the service provider accounts for the 
activity of the constituents or service consumers. Meters should be 
placed to allow for optimal data collection for the relevant 
constituency and technology. Meters are most needed at 
administrative boundaries and data collected such that service 
provider and consumer are able to reconcile their activities. 

Routers (and/or bridges) are by definition and design placed 
(topologically) at these boundaries and so it follows that the most 
generally convenient place to position accounting meters is in or 
near the router. But again this depends on the underlying transport. 
Whenever the service-providing network is broadcast (e.g., bus- 
based), not extended (i.e., without bridging or routing), then meter 
placement is of no particular consequence. If one were generating 
usage reports for a stub LAN, meters could reasonably be placed in a 
router, a dedicated monitor, or a host at any point on the LAN. 
Where an enterprise -wide network is a LAN, the same observation 
holds. At the boundary between an enterprise and a regional network, 
however, in or near a router is an appropriate location for meters 
that will measure the enterprise's network activity. 

Meters are placed in (or near) routers to count packets at the 
Internet Protocol Level. All traffic flows through two natural 
metering points: hosts and routers (Internet packet switches) . Hosts 
are the ultimate source and sink of all traffic. Routers monitor all 
traffic which passes IN or OUT of each network. Motivations for 
selecting the routers as the metering points are: 

o Minimization of cost and overhead. 

(by concentrating the accounting function) . Centralize 
and minimize in terms of number of geographical or 
administrative regions, number of protocols monitored, 
and number of separate implementations modified. (Hosts 
are too diverse and numerous for easy standardization. 
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Routers concentrate traffic and are more homogeneous.) 

o Traffic control . 

When and if usage sensitive quotas are involved, changes 
in meter status (e.g., exceeding a quota) would result in 
an active influence on network traffic (the router starts 
denying access) . A passive measuring device cannot 
control network access in response to detecting state. 

o Intermediate system accounting. 

As discussed above, internet accounting includes both 
end- system and intermediate system accounting. Hosts see 
only end-system traffic; routers see both the end-systems 
(internet source and destination) and the adjacent 
intermediate systems . 



o administrative boundaries 

only for measuring inter-domain traffic; 

o stub networks 

for measuring intra-domain traffic. For intra-domain 
traffic, the requirement for performing accounting at 
almost every router is a disincentive for implementing a 
usage-based charging policy. 



o Network monitors : 

These measure only traffic WITHIN a single network. They 
include LAN-monitors, X.2 5 call accounting systems and 
traffic monitors in bridges. 

o Line monitors : 

These count packets flowing across a circuit. They would 
be placed on inter-router trunks and on router ports. 

o Router- integral meters : 

These are meters located within a router, implemented in 
software. They count packets flowing through the router. 

o Router spiders : 

This is a set of line monitors that surround a router, 
measure traffic on all of its ports and coordinate the 
results . 



Therefore 



meters should be placed at: 



4.2. Meter Types 



Four possible types of metering technology are: 
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4.3. Meter Structure 

While topology argues in favor of meters in routers, granularity and 
security favor dedicated monitors. The GRANULARITY of the 
accountable entity (and its attributes) affects the amount of 
overhead incurred for accounting. Each entity/attribute/reporting 
interval combination is a separate meter. Each individual meter 
takes up local memory and requires additional memory or network 
resources when the meter reports to the application. Memory is a 
limited resource, and there are cost implications to expanding memory 
significantly or increasing the frequency of reporting. The number 
of concurrent flows open in a router is controlled by 

o the granularity of the accountable entity 

o the granularity of the attributes and sub-categories of 
packets 

o memory 

(the number of flows that can be stored concurrent ly / a 
limit which can also be expressed as the average number 
of flows existing at this granularity plus some delta, 
e.g., peak hour average plus one standard deviation, or 

- . .) 

o the reporting interval 

(the lifetime of an individual meter) 

There is a spectrum of granularity control which ranges across 
the following dimensions. (Most administrations will probably 
choose a granularity somewhere in the middle of the spectrum.) 

ENTITY: Entities range across the spectrum from the coarsest 
granularity, PORT (a local view with a unique designation for the 
subscriber port through which packets enter and exit "my" 
network) through NETWORK and HOST to USER (not defined here) . 
The port is the minimum granularity of accounting. HOST is the 
finest granularity defined here. Where verification is required, 
a network should be able to perform accounting at the granularity 
its subscribers use. Hosts are ultimately responsible for 
identifying the end user, since only the hosts have unambiguous 
access to user identification. This information could be shared 
with the network, but it is the host's responsibility to do so, 
and there is no mechanism in place at this time (e.g., an IP 
option, discussed in section 4.). 

ATTRIBUTE: Each new attribute requires that an additional flow 
be maintained for each entity. The coarsest granularity is NO 
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categorization of packets. The finest granularity would be to 
maintain state information about the higher- levels protocols or 
type of service being used by communicating processes across the 
network . 

VALUES: Values are the information which is recorded for each 
entity/attribute grouping. Usually values are counters, such as 
packet counts and byte counts. They may also be time stamps - 
start time and stop time, or reasons for starting or stopping 
reporting. 

REPORTING INTERVAL: At the very finest level of granularity, 
each data packet might generate a separate accounting record. To 
report traffic at this level of detail would require 
approximately one packet of accounting information for every data 
packet sent. The reporting interval is then zero and no memory 
will be needed for flow record storage. For a non-zero reporting 
interval flow records must be maintained in memory. Storage for 
stale (old, infrequent) flows may be recycled when their data has 
been reported. As the reporting interval increases, more and 
more stale records accumulate. 

The feasibility of a particular group of granularities varies 
with the PERFORMANCE characteristics of the network (link speed, 
link bandwidth, router processing speed, router memory) , as well 
as the COST of accounting balanced against the requirement for 
DETAIL. Since technological advances can quickly obsolete 
current technical limitations, and since the policy structure and 
economics of the Internet are in flux, meters will be defined 
with VARYING GRANULARITY which is regulated according to the 
traffic requirements of the individual network or administration 
and technical limitations. 

4.4. Collection Issues 

There are two implicit assumptions about the nature of meters and 
traffic sources that they measure, both of which have substantial 
bearing on collectors . 

1 . The matrix of communicating entity pairs is large but 
sparse and, moreover, network traffic exhibits considerable 
source, destination and attribute coherence - so that lists 
can be quite compact . 

2. Meters can be configured to generate either a static set 
of variables whose values are incremented, or a stream of 
records that must be periodically transferred and removed 
from the meter's memory. 
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Meters can generate large, unstructured amounts of information 
and the essential collection issue revolves around mapping 
collection activities into an SNMP framework (or, to the extent 
that this is not successful, specifying other collection 
paradigms) . 

There are three major collection concerns: 
o data confidentiality 
o data integrity 

o local and remote collection control 

The prime security concern is preserving the confidentiality of usage 
data. (See ISO 7498 Part 2, "Security Architecture, " for security 
terminology used herein.) Given that accounting data are sensitive, 
the collector should be able (or may be required) to provide 
confidentiality for accounting data at the point of collection, 
through transmission and up to the point where the data is delivered. 
The delivery function may also require authentication of the origin 
and destination and provision for connection integrity (if 
connections are utilized) . Other security services (e.g., measures 
to counter denial of service attacks) are not deemed necessary for 
internet accounting at this time. It is assumed that security 
services can be provided by SNMP and its mechanisms. (This will 
require further investigation.) 

In order to have an accurate monitoring system, reliable delivery of 
data should be assured through one or more of: 

o an acknowledgement retransmission scheme ; 

o redundant reporting to multiple collectors; 

o having backup storage located at the meter. 

There is a place for both application polling and meter traps within 
this scheme, but there are significant trade-offs associated with 
each. 

Polling means that- the collection point has some control over when 
accounting data is sent, so that not all meters flood the collector 
at once. However, polling messages, particularly when structured 
with SNMP's GET-NEXT operator; add considerable overhead to the 
network. Meter traps are required in any case (whether or not 
polling is the preferred collection method) , so that a meter may rid 
itself of data when its cache is full. 
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The fundamental collection trade-off will be between primary and 
secondary storage at the meter, coupled with an efficient bulk- 
transfer protocol, versus minimal storage at the meter and a 
network- bandwidth- consuming collection discipline. 

A final collection concern is whether packets should be counted on 
entry into a router or upon exit from a router. It is the nature of 
IP that not every packet received by a router is actually passed to 
an output port . The Internet Protocol allows routers to discard 
packets (e.g., in times of congestion when the router cannot handle 
the offered load); it is presumed that higher level protocols (e.g., 
TCP) will provide whatever reliable delivery service the user deems 
necessary (by detecting non- delivery and retransmitting) . 

The question arises, therefore , whether an internet accounting system 
should count all packets offered to a router (since each packet 
offered consumes some router resources) or just those that are 
finally passed by the router to a network (why should a user pay for 
undelivered packets?) Since there are good arguments for either 
position, we do not attempt to resolve this issue here. (It should 
be noted, however, that SMDS has chosen to count on exit only.) 
Rather, we require that an internet accounting should provide ability 
for counting packets either way on entry *to or on exit from a 
router. 

5 . Examples 

Here follows a series of examples to illustrate what data may be of 
interest to service providers and consumers in a number of different 
scenarios . In the illustrations that follow straight lines are 
interpreted as some sort of LAN. Diagonals are point- to-point 
links. Diamonds are routers. We assume that we are in a homogeneous 
protocol environment (IP) . 

5.1 A Single Segment LAN 

Consumers and providers on a single LAN service can utilize the same 
set of data : the contribution of individual hosts to total network 
load. A network accounting system measures flows between individual 
host pairs. (On a broadcast LAN, e.g., an Ethernet, this can be 
accomplished by a, single meter placed anywhere on the LAN.) Using 
this data, costs ~f or the network management activity can be 
apportioned to individual hosts or the departments that own/manage 
the hosts . 

Alternately, flows can be kept by source only, rather than source- 
destination pairs. 
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5.2 An Extended (Campus or Facility-Wide) LAN 
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This is the first example in which the information that is germane 
for service provider and consumer are not identical . The service 
consumers are now the individual subnets and the service provider is 
the facility-wide backbone. A service provider is interested in 
knowing the contribution of individual subnets to the total traffic 
of the backbone. In order to ascertain this, a meter- on the backbone 
(the longest line in the center of the illustration) can keep track 
of flows between subnet pairs . Now the communications between 
individual hosts on adjacent subnets are aggregated into a single 
flow that measures activity between subnets. 

The service consumers, or subnets, might in turn want to keep track 
of the communications between individual hosts that use the services 
of the backbone . An accounting system on the backbone could be 
configured to monitor traffic among individual host pairs. 
Alternately an accounting system on each individual subnet could keep 
track of local and "non-local " traffic. The observed data of the two 
sets of meters (one for the service provider and one for the service 
consumers) should have reconcilable data. 
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5.3 A Regional Network 
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In this example we have a regional network consisting of a ring of 
point-to-point links that interconnect a collection of campus -wide 
LANs . Again service provider and consumer have differing interests 
and needs for accounting data. The service provider, the regional 
network, again will be interested in the contribution of each 
individual network to the total traffic on the regional network. 
This interest might extend to include measure of individual link 
utilization, and not just total offered load to the network as a 
whole. In this latter case the service provider will require that 
meters be placed at one end or the other on each link. For the 
service consumer,, the individual campus, relevant measures would 
include the contribution of individual subnets or hosts to the total 
"outbound" traffic. Meter (s) placed in (or at) the router that 
connects the campus- network to the regional network can perform the 
necessary measurement . 
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5.4 A National Backbone 
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In this last case, the data that the service provider will want to 
collect is the traffic between regional networks. The flow that 
measures a regional network, or regional network pairs, is defined as 
the union of all member- campus network address spaces. This can be 
arrived at by keeping multiple individual network address flows and 
developing the regional network contribution as post -processing 
activity, or by defining a flow that is the union of all the relevant 
addresses. (This is a cpu cycles for memory trade-off.) Note that 
if the service provider measures individual network contributions, 
then this data i&r in large 
measure, the data that the service consumers would require. 

Future Issues 

This last section is the collector for ancillary issues that are as 
yet undefined or out of current scope. 
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APPLICATIONS standards: Recommendations for storage, processing and 
reporting are left out for the moment. Storage and processing of 
accounting information is dependent on individual network policy. 
Recommendations for standardizing billing schemes would be premature, 

QUOTAS are a form of closed loop feedback that represent an 
interesting extension of usage reporting. But they will have to wait 
until the basic accounting technology is reasonably defined and has 
been the subject of a reasonable amount of experimentation. 

SESSION ACCOUNTING: Detailed auditing of individual sessions across 
the internet {at level four or higher) will not be addressed by 
internet accounting. Internet accounting deals only with measuring 
traffic at the IP level. 

APPLICATION LEVEL ACCOUNTING: Service hosts and proxy agents have to 
do their own accounting for services, since the network cannot 
distinguish on whose behalf they are acting. Alternately, TCP/UDP 
port numbers could become an optional field in a meter, since the 
conjunction of a pair of IP addresses and port numbers occurring at a 
particular time uniquely identifies a pair of communicating 
processes . 

The USER has not yet been defined, since an IP option would have to 
be added to the IP header to provide for this. This option would 
probably contain two parts - a subscriber identification and a user 
sub- identification - to allow for the later introduction of quota 
mechanisms which have both group and individual quotas . The 
subscriber is the fiscally responsible entity, for example the 
manager of a research group. In any case/ routers must be able to 
fall back to accounting by host, since there will most certainly be 
hosts on the network which do not implement a new IP option in a 
timely fashion. 
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Security Considerations 

Security issues are discussed in sections 2, 3 and 4. 
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METHOD AND APPARATUS FOR 
RATE GOVERNING COMMUNICATIONS 



Field Of The Invention 

The present invention relates to communications and more 
particularly an improved method and apparatus for transferring data 
10 in a communications system. 



Background 

The last 10 years have seen a tremendous increase in the 
demand for communications services, including both wired and 

15 wireless networks capable of handling data communications. Unlike 
real-time voice services, such as standard telephony or cellular 
wireless services, in which circuit-switched communications are 
used because of the sensitivity of users to the timing of oral 
dialogue/voice data, greater efficiencies can often be achieved in 

20 non-voice data communications through the use of packet-switched 
or hybrid communications systems. This is particularly the case 
with communications to remote users (e.g., persons sending 
messages via one of the well-known available wireless networks 
like GSM ^Global System for Mobiles) or AMPS (Advanced Mobile 

25 Phone System) cellular), where protracted circuit-switched sessions 
into a mail server or LAN (local area network) could be prohibitively 
expensive due to the high per-minute session charges by the wireless 
service provider. 

One solution to this problem has been for users to limit, as 
30 much as feasible, their communications to sessionless 
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communications. This can be done, e.g., by subscribing to additional 
email services that can receive LAN/WAN (wide area network) email 
and send out broadcast pages and transmissions to registered users, 
in lieu of requiring a user to maintain a session with a mail server. ' 
However, this disadvantageously requires subscription to an 
additional service, and is typically limited in the types of 
applications supported. With the rapid growth in emerging session- 
oriented applications-like the popular client server application of 
Lotus Notes^-the need is growing for more cost effective solutions 
to providing connectivity of such session-oriented applications and 
users remotely located from their host servers. 



Regardless of whether a session-oriented or session-less 
communication service is used, it is also desirable to limit the 
amount of information communicated between a remote user and 

5 host, both to save off-site user's time and to limit the costs arising 
from the more expensive rates for remote communications. 
Unfortunately, typical applications like email do not provide for 
user-selected methods for choosing and limiting the volume of down- 
loaded communications, or for filtering uploaded or downloaded 

() communications. Thus, a user who wants to receive remote 

messaging is left with an option of receiving all his messages (or 
some summary thereof), even the ones he or she might otherwise be 
willing to leave unprocessed until a later time when no longer using 
expensive remote communications services. Further, many 
processes, like that of a typical email reply, are wasteful of 
bandwidth by resending all earlier messages each time a new reply is 
generated, even though the earlier messages may still be stored at 
both ends of the wireless network. 

In addition to the above concerns over how to optimize the 
types and amount of data being transferred, there is additionally a 
problem in a lack of effective techniques for monitoring and even 
controlling an aggregate use of tariffed networks. While the network 
service providers have means for tracking use by an individual unit 
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basis, which is totaled in periodic billing statements, this 
information is typically unavailable to users or their 
managers/application administrators. Thus, users and managers are 
typically left without any effective means for controlling the level 
5 of messaging during a billing cycle, and can only monitor or react to 
usage following the service providers periodic statements. 

There remains therefore a need for an improved means for data 
communications that solves these and related problems. 



10 Brief Description Of The Drawings 

FIG. 1 is a block diagram of a communications system according 
to a first embodiment of the invention; 

FIG. 2 is a block diagram of a communications system according 
to a further embodiment of the invention; 

15 FIG. 3 is a flow chart illustrating virtual session data transfer 

between the different functional entities of the wireless 
communications system of FIG. 2; 

FIG. 4 is a flow chart illustrating a pre-stage filtering 
embodiment for data transfer between the different functional 
20 entities of the wireless communications system of FIG. 2; 

FIG. 5 is a flow chart illustrating one embodiment of pre-stage 
filtering for_ data transfers; 

FIG. 6 is a flow chart illustrating another embodiment of pre- 
stage filtering for data transfers; 

25 FIG. 7 is a flow chart illustrating a message summarization and 

selection embodiment for data transfer between the different 
functional entities of the wireless communications system of FIG. 2; 
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FIG. 8 is a diagram illustrating an embodiment of a summary 
index for use in the process of FIG. 7; 

FIG. 9 is a flow chart illustrating an optimized reply 
embodiment for data transfer beiween the different functional 
entities of the wireless communications system of FIG. 2; and 

FIG. 10 is a flow chart illustrating a rate governor embodiment 
for data transfer between the different functional entities of the 
wireless communications system of FIG. 2. 



Detailed Description 

These problems and others are solved by the improved method 
and apparatus according to the invention. A presently preferred first 
main embodiment of the invention is a system including a virtual 
session manager (VSM) for establishing and maintaining a 
sessionless communication path with a first data processing device 
(e.g., a mobile client) on the one hand and a session-oriented 
communication path with a second data processing device (e.g., a host 
system). The session-oriented communication protocol (including 
network and application layer protocols) with the host system 
permits remote access to, e.g., LAN-based applications, while the 
virtual session, via a sessionless-oriented communication protocol, 
between the VSM and remote (i.e., coupled via a tariffed network or 
connection) client permits this access to be carried out without the 
expense of a dedicated/circuit switched connection. 

In a second main embodiment, a prestage filter stage is 
provided for applying user-definable filter parameters (e.g., reject, 
pass, or granularity filters) on data being transferred between the 
remote communication unit and communication server. For 
downloading, e.g., email from a host post office, a communication 
server controller preferably either forwards the filter parameters in 
a query object or message to the post office to apply and return 
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qualified mail, or the communication server receives all unprocessed 
mail and applies the filters locally, only acknowledging as processed 
that mail which is qualified. For uploading, e.g., email from a client, 
a client controller applies an upload prestage filter so as to retain 
5 all filter rejected mail, while transmitting mail passing the filters. 
Thus, only desired data transfers (i.e., those meeting user defined 
filters) are communicated over the expense-bearing networks 
between the remote unit and communication server. 

In yet another main embodiment, a select and summary (S&S) 

10 listing or index is used to provide user flexibility in reviewing and 
requesting otherwise filtered data. Both the user's remote 
communication unit and communication server maintain a S&S index 
containing identifying (summary) information about data which has 
not been fully transferred between the communication unit and 

15 communication server. As new data is reviewed and filtered for 

transfer, identifying/summary information is captured for any non- 
qualifying data by either a host unit or the communication server. 
This information is stored in the communication server's S&S index, 
and at least periodically, or upon request, transferred via update 

20 messaging to the remote communication unit. Upon reviewing its 

updates or its S&S index, the user may send a request for such of the 
data that it desires partial or full transfers for further review. 
Thus, a cost efficient review mechanism is provided to users for 
determining whether to transfer data that otherwise fails selected 

25 filter parameters. 

In a fourth main embodiment, a method and apparatus for 
optimized reply to messaging is provided. When sending a reply, the 
remote communication unit's controller generates a delta (e.g., data 
representing the content difference between two messages) between 
30 a preceding message and the reply message, and forms an optimized 
reply using the delta and an identifier of the preceding message. On 
receiving the optimized reply, the communication server uses the 
data unit identifier to retrieve the preceding message from a further 
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host (e.g., the post office mailbox of the user associated with the 
remote unit), reconstructs the full reply from the retrieved message 
and the delta, and forwards the full reply to the addressee. When 
receiving a reply for the remote unit, an index is preferably 
maintained at both the remote unit and communication server of mail 
stored at the remote unit. Resort is made to this index to determine 
a preceding message forming part of the reply. An optimized reply is 
similarly formed from a delta and identifying information of the 
preceding message, and sent to the remote unit. In this manner, the 
volume and expense incurred in reply messaging is greatly reduced, 
by only sending a delta and small header (i.e., the identifying 
information). 

Finally, in a fifth embodiment, a rate governor is provided for 
monitoring and controlling the amount of communications between 
the remote unit and communication server. Preferably, as 
threshold(s) are passed a user is alerted to amounts (time and/or 
charges) spent or remaining, and once a use limit is reached further 
communication is restricted. A main rate governor is maintained at 
the communication server, allowing access, control and the like by 
system administrators and the like. A further rate governor, 
responsive to the main rate governor, may also be used at the remote 
unit. By means of this rate governor a mechanism is provided for 
both limiting user or group data transfer beyond a set amount, as 
well as providing alerts to users as the limit is approached. 

Turning now to FIG. 1, there is generally depicted a 
communication system 100 in accordance with a first embodiment of 
the invention. This system is configured to support one or more user 
devices such as wireless subscriber units (i.e., mobile station (MS) 
105) communicating with host processor 115 via an infrastructure 
including base station 120 and intermediate system 125 coupled to a 
data network 130. In the illustrated case mobile station 105 is a 
portable computer having an rf (radio frequency) modem 106. A 
communications server 110, including a virtual session manager 
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(VSM) and query manager (QM), is coupled between the public data 
network 130 and the host server 115. The virtual session manager 
and query manager are, preferably, an appropriately configured data 
processing device, the VSM and QM program being shipped for loading 
5 on the server 110 via any convenient means such as a machine- 
readable CD-ROM 1 1 1 (compact disc-read only memory) or the like. 
Counterpart client-communications software, e.g., a prestage filter, 
can be shipped via a similar convenient form like CD-ROM 107, 
downloaded directly from server 110 to subscriber 105 (also being, 
10 e.g., a data processing device, by which is meant virtually any 
processor (but not a human) capable of processing data for a 
programmed result, whether a general purpose computer or more 
specialized electronic processor), or the like. 

In this embodiment the mobile user 105 communicates with the 

15 server/VSM 110 using any appropriate data protocol being used by 

the data network 130, as necessarily modified for transport over the 
wireless infrastructure; the wireless infrastructure could be, e.g., 
any private system like ARDIS^ or DataTAC^, CDPD (cellular digital 
packet data), GPRS (GSM Packet Radio Service), and the like. Thus, a 

20 sessionless data flow between the mobile user 105 and server/VSM 
110 occurs on an event driven basis, and no costly connection is 
maintained when there is nothing being communicated. In order to 
keep connectivity costs to a minimum, the server 110 is preferably 
connected to the LAN/WAN on which the host 115 is also connected, 

25 via any standard LAN/WAN communication channel (e.g., a bus or 
backbone). This allows the communications server 110 to 
advantageously maintain the same session with the host 115 that the 
client 105 typically enjoys when connected to the LAN/WAN. Thus, 
by use of the server 110 the client 105 can achieve a virtual session 

30 with the host 115 with almost the same access as if directly 

connected to the host's 115 LAN, but at a substantial reduction in the 
cost of communicating via the wireless network and PDN 130. 
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FIG. 2 illustrates an alternative communication system 200 
embodiment of the present invention. A first client, a mobile end 
system (M-ES) computer including a user device 201, is in 
communication with a base station (BS1) 218 of a wireless 
5 communication system. This base station 218 is coupled, e.g., on a 
same bus or via bridges/routers, to a communication server 220 
which includes VSM 230. An electronic mail (email) post office is 
coupled locally to VSM 230, either as another program running on the 
same communications server 220 or located on another server 240 of 
10 the communications server's 220 LAN/WAN. It is not important, 

however, where the post office is located for purposes of operation 
of the VSM 230, as is illustrated by other application hosts B and C 
255, 260 being in communication via other networks such as a public 
data network or public switched telephone network 250. In fact, the 
15 same user 201 could be concurrently coupled via the VSM 230 to, for 
example, a local email post office 240, a remote client-server host 
255, a further database host server (not shown), an administrator 
host server 260, a multimedia host, a voice processor, etc. It should 
be understood that for purposes of this application, a first device or 
20 component is responsive to or in communication with a second unit 
or component regardless of whether the first and second units are 
directly coupled or indirectly coupled, such as via intermediate 
units, including switches that operatively couple the units for only a 
segment of time, as long as a signal path can be found that directly 
25 or indirectly establishes a relationship between the first and second 
units. For example, the client computer 105 is in communication 
with the VSM. server 110 even though intermediate system (e.g., a 
router or switch) 125 and a packet network 130 having multiple 
switches etc. are disposed between the user device 105 and VSM 
30 server 110. 

In the illustrated case client 201 includes a data transfer 
manager or exchange unit 206, which in simple form could be an 
appropriately programmed electronic processor 207 (e.g., a general 
purpose CPU (central processing unit) and memory or data store 211. 
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A timer 205 is also preferably employed in the data exchange control 
process, as will be explained further in connection with the flow 
chart of FIG. 3 below. A typical client 201 would also include some 
forrn(s) of user interface such as display 204, a data 
5 encoder/decoder 203 to accommodate the system communications 
protocol(s), and a transceiver (if using rf or infrared 
communications) and a modulator-demodulator (or modem) 202 to 
connect to a wireless or wireline communications network. 
Transceiver/modem 202 in this case would either include a built-in 

K) or attached user module for wireless LAN communications; the 
specific type will vary depending on the system, e.g., including 
PCMCIA (personal computer memory card interface association) 
wireless modems, and attached or built-in PSTN (public switched 
telephone network) modem, etc. Specific features of data exchange 

15 unit 206 preferably includes (as more fully described below) a 
prestage filter (PSF) manager 208, rate governor (RG) 209, user 
profile store 212, select and summary index store 213. and mail 
store 214 (a store being any available device (e.g., ROM (read-only 
memory), disks) or program (e.g., a database) for storage of the 

20 specified information). 

The communication server 220 preferably includes a data 
transfer manager or controller 229 having a VSM 230, memory stores 
for storing active client profile (user parameters) and inactive client 
profile information 226 and 227, a timer 224, and optionally some 

25 form of protocol translators or formatters 222. The VSM 230 serves 
to manage the virtual session with the client 201 and session with 
host system^ 240, 255 and/or 260 based on the parameters loaded 
into the active user parameter store/profile memory 226 or object. 
Controller 229 preferably also includes a query manager (QM) 231 for 

30 controlling specific processes (e.g., sending messages to a post 
office to query for unprocessed messages and forwarding received 
messages etc.), and a prestage filter 232 and rate governor 234. 
Memory 225 also preferably includes a client select and summary 
index database or store 228, which will also be described more fully 



WO 97/22936 



PCT/US96/19689 



10 

below in connection with FIGS. 7 and 8. The protocol translators 222 
serve to format or code the messages as appropriate for transport 
between the VSM 230 and client 201; these include, e.g., appropriate 
protocol software that can be located at the communications server, 
or any other convenient processor per design of the given 
communication system. By messages is meant any appropriate data 
unit (whether a frame, datastream. packet, or other format), 
including objects, datagrams, etc., for containing information being 
communicated. 

Communications server 220 is also illustrated as supporting 
additional users, e.g. user module 216. communicating via different 
access points, e.g., control module (CM) 217 of a wireless LAN and 
base station 219, all access points 217-219 being coupled via a 
common bus, backbone, etc. These base stations can be part of the 
same communication system, similar systems owned by different 
service providers, or even different systems, all of which may be 
different from the communications server service provider. Thus, 
for example, a single communications server can support at one local 
region 215 an ARDIS (,<) node, a RArVP' node, a wireless LAN controller 
module, a CDPD node, an in-building cordless telephone node, etc., 
allowing users from a variety of systems to access the same 
communications server and post office. Users not registered could 
access through the appropriate one of these nodes along the model of 
FIG. 1, i.e., via PDN 250 to a remote communications server having 
their VSM/QM. Thus, any number of system configurations is 
possible, limited only by the network services provided and the 
user's preference. 

A process by which a VSM manages communications between 
client and host is illustrated in the flow chart embodiment of FIG. 3. 
This process typically begins with a user event, such as instantiation 
(forming) of a communications object at the client and sending a 
registration message (steps 301-302). Alternatively, the 
infrastructure could initiate the communications by sending a page 
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or the like requesting the client to register (for example, when the 
client has registered with the wireless system but not yet requested 
registration with the communications server). In any event, once a 
registration message is received by the communications server, it 
5 preferably authenticates and otherwise qualifies the client, 

including sending a logon/registration message to the host for its 
authentication of the client (steps 303-305). Upon successful 
authentication, the communications server instantiates a client 
object (CO) for the communications session including client 

10 parameters retrieved from an inactive client parameter store, as 
modified by the user in his registration or subsequent messages 
(step 306). These parameters include at a minimum client and host 
identifiers, but may also inciude additional preferences based on the 
type of communications involved. Also, the registration and 

15 authentication process can be handled by the VSM, or alternatively by 
another appropriately programmed entity of the communications 
server. Following instantiation at the server, a response message, 
e.g., a further registration message, is sent to the client, and an 
acknowledgment (ACK) returned to the server; both client and server 

20 then retain the instantiated objects as fully qualified, and may start 
session timers (steps 307-309). At this point a virtual session has 
been established between the client and the VSM, and a regular 
session established between the VSM and host computer. If the 
registration is not successful, then any instantiated object is 

25 deleted, with the client returned to an inactive status. 

Upon establishing the virtual session, a query is preferably 
generated by query manager requesting unprocessed data for the user, 
and the VSM forwards the query to the host (step 320). In the case of 
email, e.g., this might include generating a request message for all 
30 unread mail in the users post office box. The post office then checks 
for new mail received, and forwards all such mail to the VSM (steps 
321-322). Because the VSM has established a LAN session with the 
post office, these communications are performed relatively quickly, 
e.g., in accordance with the LAN's and host's typical processing for 
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their current loading level. The VSM in turn forwards the data (i.e., 
mail) received via the virtual session transport (step 323). For 
example, in the case of FIG. 1 where PDN 130 is an ISDN (integrated 
services digital network) network connected to a CDPD wireless 
network, the mail would be appropriately packetized by the 
communications server and delivered via the serving BS 120 
according to ISDN/CDPD system protocols. This can take up to 
several minutes or more for a moderately sized mail package. 
However, since the data is being delivered in a sessionless mode, the 
amount of time the communication channel (including the more 
expensive wireless communication channel portion, as well as the 
portion via PDN 130) is tied up is kept to a minimum. This also 
translates into a significant cost savings for the user, since the user 
is only charged on a per packet basis for mail when it is actually 
15 transported, and doesn't have to pay for a prolonged session to keep 
connected to the post office in order to receive new mail. Finally, 
upon receipt by the client, appropriate acknowledgments are sent and 
the post office box updated, e.g., by marking the mail as read or 
processed (steps 324-326) 

20 While in some systems it may be advantageous to store some of 

the data at the communications server, in the case of email and the 
like it is presently -envisioned that the communication server is 
preferably used in maintaining the sessions between client and host, 
and not as a remote server for the host. Thus, rather than have all 

25 new data from the host pushed down to the communications server, 
most data exchanges are preferably initiated, at some predetermined 
interval or intervals, by the communications server (e.g., by the query 
manager). 



30 



Further, it is an -inefficient use of resources to continue 
querying a host or attempting to deliver data when the client is no 
longer receiving at its remote location (occurring, e.g., when the 
client leaves a coverage area, or the user turns off its modem or 
processor). Thus, a process for either maintaining the client in an 
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active status, or removing the client from active status in response 
to an event, is also preferably included in the VSM. One such process 
is to utilize timers at both client and VSM to determine when a 
virtual session is no longer active. The timers are first set upon 
5 registration, and are subsequently reset after each data exchange 
(steps 327-336). If no data exchange occurs within a predetermined 
period of time, say 20 minutes, both client and VSM would remove 
the client qualification (i.e., destroy the client object for the 
communication session) and, if desired, mark the client as being in 

10 an inactive status (steps 337-340). The VSM would also forward a 
logoff message to the host (step 341). In order to avoid an undesired 
time out, the client is preferably configured to send a short message 
after a predetermined period since the last data exchange, 
sufficiently prior to the time at which the timers elapse so that the 

15 VSM can receive it. Otherwise, if there are only intermittent data 
exchanges, the client may be required to frequently re-register; this 
in turn means the client will not be notified of outbound data until 
the client re-registers and is again coupled via the virtual session 
manager. 

20 Turning now to FIGS. 4 through 6, a presently preferred 

embodiment is shown for prestage filtering data for transfer 
between the different functional entities of the wireless 
communications system of FIG. 2. This typically begins with the 
generation of a query object or message at the communications 

25 server (step 406). This object/message may be created in response 
to a preceding client generated message (e.g., a request generated 
when clicking on an application button requesting updates, executing 
the mail application, etc.), or in response to settings in the client 
profile. However, after updating the active client profile/object for 

30 an active client application, the query manager is preferably 

programmed to send query objects at predetermined intervals for 
each application being run by each active client, the intervals varying 
depending on the application type or administrator preference (e.g., 
for mail about every 10-30 seconds or longer). Alternatively, the 
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intervals could be user specified via the client profile, for example 
to shorten the query intervals for time critical applications (e.g., for 
emergency services or "real time" applications) , or lengthen the' 
intervals when less frequent updates are desired (e.g., to conserve on 
traffic expenses for updates to a rapidly changing, but non-time- 
critical, group-ware file or document). 

The content of the query objects will vary depending both upon 
the application and client filter settings. One approach for mail 
applications is to have a predetermined number of user-definable 
filter attributes stored in the client profile databases (e.g., stores 
212 and 226-227 of FIG. 2). These attributes can include, by way of 
example, the priority of a message (e.g., urgent, normal, or low); the 
date on which the message is sent or posted; the size of the message 
(typically uncompressed, i.e., the normal stored size; although 
transmission size or cost could also be used); the author of the 
message; and the subject of the message (e.g., key words in a subject 
line or in the text). These attributes can simply be used as reject 
criteria (e.g., reject all messages having "low" priority, date before 
"12/1 5/95", size more than "2" kbytes (kilobytes), or subject not 
containing "project x"), pass criteria (all messages from "Boss") or a 
combination of both, the variety and complexity being a matter of 
design choice, these attributes also preferably include certain 
"granularity" filters, i.e., filters additionally limiting the size of a 
message passing all or most of the other filters. Three possible 
examples of granularity filters are a truncation size filter (e.g., 
truncate the message after the first "100" bytes), and text or file 
attachment filters (e.g., indicating whether or not to strip 
attachments). Thus, messages passing all criteria but message size 
could still be received in a truncated size meeting the message size 
criterion. Alternatively, messages failing the author or subject 
filters could still be passed with header information, by setting all 
rejected messages to be passed with a text truncation size of "0" 
bytes. One skilled in the art will appreciate that a variety of other 
reject/pass filter criteria may be used, and the specific ones and 
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combinations of user-definable (or even administrator-definable) 
features will be largely a matter of design choice depending on 
factors such as the desired functionality, complexity, and 
application(s) (including filterable features). It is significant, 
5 however., that clients are now provided by the present invention with 
a means for effecting prestage filtering of their communications by 
virtue of the communications server and definable filter settings, 
rather than having to choose between receiving no messages or 
receive all messages, including less important or expensive and 
10 time-consuming transmissions. 

The prestage filtering is preferably performed at the host 
server. This may be accomplished, for example ; by passing the filter 
attributes in an appropriately formatted query object or message for 
use by the host application. In the illustrated case a query object 

15 with the client filter settings is forwarded to the post office, and 
applied by a communications server object or CSO (instantiated at 
the post office when the virtual session is established). The post 
office/CSO reads/queries the query object for the filter attributes, 
and applies these criteria in the selection and formatting of 

20 unprocessed messages (steps 408-412). The filtered messages are 
then encapsulated and forwarded to the QM, which similarly forwards 
the filtered messages (with appropriate protocol translation) to the 
client (steps 414-416). Alternatively, where the host application is 
not designed to permit prestage filtering, all unprocessed messages 

25 can be forwarded to the communications server, where the filters 

are applied via a prestage filter (PSF) object or routine (e.g., PSF 232 
of FIG. 2), ~with only qualifying/filtered messages being forwarded to 
the client (steps 410, 418-424). Through acknowledgments the post 
office is notified how to mark the mail index in both cases. For 

30 example, when prestage filtering at the post office, all forwarded 
mail would be marked as processed/read and all filtered mail as 
unprocessed (truncated messages being marked as either depending 
on design conventions, or if available marked as filtered or partially 
processed). If prestage filtering is done at the communications 
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server only those messages forwarded to the client would be 
acknowledged and marked as processed (step 428). 

In addition to download/downlink filtering, prestage filtering 
is also advantageously used in upload/uplink transmissions. This can 
take the form of granularity filtering, or automatically retaining the 
whole data unit or message based upon filterable attributes for later 
transmission when on a lower cost network. In this case, each client 
would have a prestage filter (PSF) unit such as that of PSF 208 of 
FIG. 2 (e.g., a PSF object or routine drawing on selected attributes in 
the profile store 212). Each data unit generated is filtered using the 
user-selected criteria, with qualifying data being forwarded via the 
communication server (steps 430-436). If a data unit is not sent, it 
is retained locally for transmission later, e.g., when connected via a 
lower cost network to the post office. As an enhancement, the user 
could additionally be provided with a selection of types of send 
buttons (i.e., filtered send or unfiltered send), or be prompted with an 
alert dialogue or similar message when a message is filtered to 
decide whether to forward the data unfiltered (steps 438-440). 
Similarly, the user can be provided with several groups of filter 
settings that could be manually or automatically activated, so as to 
enable the client to adjust plural filter settings with a minimum 
effort, for example by switching to a more restrictive profile when 
entering important meetings (which profile could be automatically 
activated via an appropriately configured and coupled calendar 
program, etc.). 

While only the client heed retain the upload filter attributes in 
its profile store, preferably both the communication server and 
client store copies of the download filter settings in their profile 
memories. This conveniently permits a client to review all settings 
whenever desired, and to change the settings locally. When the 
download settings are changed at the client, the changes are 
communicated to the communication server preferably as soon as the 
change is made, or as soon as a virtual session is established if the 
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changes are made while offline from the communication server 
(steps 442-444). Further, where a summary index of filtered 
messages is maintained (as is described in connection with FIGS. 7 
and 8 below), upon a change in filter settings the communication 
5 server may be automatically set to forward all messages previously 
rejected but now passing the new filter settings. 

FIGS. 5 and 6 illustrate two approaches to prestage filtering 
particularly useful for email filtering. In FIG. 5, a series of five 
reject filters are applied to each message. If a mail message does 

10 not meet any of the criteria (priority, date, size, author, or 

subject/key word) then it is left unprocessed (steps 502-516). Once 
all unreviewed messages (i.e., all unprocessed messages, or if 
expanded marking is available all unprocessed messages not 
previously filtered) have been filtered, those not rejected are 

15 forwarded (step 518). FIG. 6 illustrates the application of 

granularity filters. If a message exceeds the filter size, it is 
appropriately truncated (including insertion of a note indicating 
truncation) (steps 602-606), Similarly, if there are text or file 
attachments, and these are marked to be filtered, they are stripped 

20 with, optionally, a note being inserted alerting the addressee that 
the attachment was stripped (steps 608-614). Once filtered, the 
message is sent (step 616). 

FIGS. 7 and 8 illustrate a further enhancement, permitting the 
user to more conveniently review selected information even for 

25 filtered/rejected data. In the preferred embodiment a query object 
or message-is similarly generated by the communication server as 
described above. However, in addition to the profile information, the 
query object in this case includes a request for summary information 
about each partially and fully rejected message (step 702). When the 

30 host (i.e., a post office server in the illustrated case) receives the 
query it applies the appropriate filters; if only qualifying mail is 
present, this is forwarded to the client as described above (steps 
704-708). Where there is partially (e.g., truncated) or fully rejected 
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data, identifying summary information is captured for all rejected 
data (step 710). For mail this identifying summary information 
would include the message serial number, along with certain header 
information (801 and 802 of FIG. 8). This header information may 
include any filterable attribute (e.g., date, author, subject, size, 
priority, attachment indicator) and is preferably client definable, so 
the cl.ent can decide how much header information it needs and how 
much to omit. All qualifying and non-qualifying (i.e., filter-rejected) 
mail is marked similarly as described above (step 712). 

When the response object or message is received by the QM of 
the communication server, the encapsulated identifying summary 
information is saved to a select and summary (S&S) index, such as 
that illustrated by client S&S index database 228 of FIG. 2 and the 
index structure of FIG. 8. This index is preferably created in 
response to the first query following full qualification, although one 
could retain a stored index when the client is inactive as long as the 
index is fully updated upon re-registration/ qualification. In order to 
minimize transmissions between the communication server and the 
client, only changes to the S&S index are forwarded, as summary 
delta data (i.e., a delta of the revised index to the immediately 
preceding index, the preceding index being an acknowledged version 
same as that stored, in the S&S index (e.g., S&S index database 213 of 
FIG. 2) of the client). Where only identifying summary information is 
received in response to the query object, one may additionally delay 
forwarding the delta information to the client for a predetermined 
period of time or until the next message passing the prestage filters 
is forwarded, whichever comes first (i.e., the filter-rejected 
information more likely being less important, some users may prefer 
to receive S&S index updates less frequently in order to further 
reduce costs or interruptions) (steps 714-718). 

Upon receiving the delta of the identifying summary 
information, the client updates its S&S index and, when appropriate, 
prompts the user (again, the prompt criteria could be set for all 
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messages, or some sub-set based on any filterable attribute, etc.). 
The user is thus able to review the summary information and make a 
determination on whether or not to override the filter rejection. For 
. mail the user wants to read, the user indicates the decision by any 
5 appropriate means (clicking on the message, voice command, etc.) and 
an appropriate request generated (e.g., for all selected mail, for only 
a partially filtered version (e.g., truncated), etc.) (steps 720-722). 
The request is appropriately translated, as needed, and sent as a 
query object or message to the post office. Upon retrieval, the 

10 requested data is forwarded to the client via the QM. Upon receipt at 
the client, a read acknowledgment may be generated and sent to the 
communication server. Preferably when the read acknowledgment is 
received at the communication server a further ACK 
(acknowledgment signal) may be sent to the client, at which time 

15 both client and communication server update their respective S&S 
indices to remove the entry for read mail from the S&S index, and 
note any partially read mail. Upon acknowledgment, the post office 
may further mark any read mail as processed (steps 724-734). 

As with prestage filtering, one skilled in the art will 
20 appreciate that many more filterable attributes and summary inputs 
are possible than those described, and which ones are available will 
depend on such factors as the desired functionality, complexity, and 
application(s) (including filterable features) for which the select and 
summary index is being used. The index structure may thus similarly 
25 vary significantly, as will the means for achieving similar indices 
for both the client and communication server; in other words, while 
one could simply periodically forward the whole index, where 
practical any one of a number of known delta (e.g., data representing 
the content difference between two files) or other update approaches 
30 for communicating less than the whole index are likely more 

preferable. What is significant, no matter the particular design 
approach selected, is that a summary index, showing unprocessed or 
partially processed data (e.g., that filtered), is available to a client 
for determination on whether to process the data further, with a 
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substantially identical index being retained at the communication 
server in order to further reduce transmission requirements. 

FIG. 9 illustrates a yet further improvement, this embodiment 
permitting a user to minimize the data transmitted for responses to 
earlier data transmissions. This is particularly advantageous in the 
case of email, where it is common to append all prior messages in an 
email conversation to a reply, making for lengthy reply messages 
that contain substantial portions that are identical to mail already 
saved at the client or target unit. While this has come to be expected 
in email replies, it is also quite costly in time and tariff charges in 
bandwidth limited systems like most wireless communication 
systems. 

Starting from a client perspective, the process of FIG. 9 
commences with a client formulating a reply to a received mail 
message, much as he or she would for any typical email application 
(step 902). However, when the user executes the reply, e.g., by 
clicking on a send button, the client controller (201 of FIG. 2) 
optimizes the reply message by calculating a delta or difference, 
using any appropriate delta routine, between the reply message and 
the preceding message. This delta is then formed into an optimized 
reply along with a' message/data unit identifier for the preceding 
message/data unit (preferably the mail serial number, although any 
retrievable identifier of the preceding message may be used, such as 
header information, or even a CRC (cyclic redundancy check) value) 
(step 904). To ensure that only the shortest message is being sent, 
the controller additionally compares the reply message with the 
optimized reply to determine which is optimum for transmission 
(step 906). This determination may be made based on a comparison 
of the message sizes, compressed and formatted message sizes, or 
any other convenient means for estimating which version of the reply 
will require the least bandwidth or transport cost. Thus, for 
example, a normal reply message to a very short message may be 
selected for transmission where the overhead of the delta and 
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message identifier make the optimized reply bigger than the normal 
reply message would be. However, in most instances it is 
anticipated that the optimized reply will be smaller than a normal 
reply message, providing significant savings to the client in time and 
5 costs. 

When the optimized reply is received at the QM of the 
communication server, a determination is made on whether to 
reconstruct the normal reply message (i.e., form a replica reply) or to 
forward the optimized reply, based on known parameters (if any) ot 
the target communication unit/client. Thus, for example, where both 
the originating and target clients are active and served by the same 
communication server and thus are known to have optimized reply 
capabilities, and the target client was an addressee or originator of 
the preceding message identified by the message identifier of the 
optimized reply, a reconstructed reply may not be required. Rather, 
since the preceding message would either be in the inbox or outbox of 
the target unit, the target unit can reconstruct the reply message 
from the identified mail in its mailbox and the delta. This 
advantageously allows bandwidth to be minimized for both the 
sending and target clients. Further, if perchance the target unit has 
already deleted the identified preceding message, the controller of 
the target unit could, rather than acknowledge receipt, send a 
request for the normal reply message, which the communication 
server would reconstruct as described next. 

25 In cases where the target unit is not an active client with the 

communication server, the QM (or other appropriate entity of the 
controller) functions to reconstruct the reply message from the 
optimized reply. Because the communication server preferably does 
not retain a copy of client mail or data located on other hosts (such 

30 remote stores typicaliy adding complexity and cost, while being 
unnecessary in view of the virtual session established via the 
communication server), it would use the identifier to retrieve the 
preceding message from the host (e.g., send a query object or 
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message to the appropriate post office) (steps 908-912). This can be 
implemented by requesting the preceding message from the client 
inbox, or from the originating unit's outbox (or even the target unit's 
inbox, if it is a cc: on the preceding message). Because the serial 
number is a unique number widely used in email applications, this is 
the preferable message identifier for email systems. However, 
where this unique number is unavailable other identifiers may be 
used, including author, date and/or subject matches. Further, for 
some messages it may even be advantageous to use other relatively 
unique values, such as CRC or other values, by themselves or together 
with other identifiers. It is relatively unimportant for purposes of 
the invention what the identifier is, as long as it is useful within the 
accuracy demanded by the system design for retrieving the correct 
preceding message. 

Once the preceding message has been received by the 
communication server, it uses a counterpart delta routine to that of 
the client to reconstruct a replica of the reply message from the 
delta of the optimized reply and the retrieved copy of the preceding 
message. Once reconstructed, the reply message is forwarded to the 
target unit(s), as well as to the outbox or sent mail folder of the 
client's post office box (steps 914-916). While some additional 
processing and network traffic is required between the 
communication server and host, this is relatively inexpensive 
compared to the savings achieved by using an optimized reply over 
the tariffed network between the communication server and client. 

While the preceding approach can be implemented without 
resort to a message index, it can be further optimized by use of 
indices at the communication server and client. In this case, a full 
index of each active client's mailbox (or other application file(s)) is 
maintained at both the client and the communication server. This 
index could advantageously be one of the S&S indices 213 and 228 of 
FIG. 2 designed to include all mail (although perhaps with less 
identifying information for received mail than for filter-restricted 
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mail, depending on factors such as the memory available and the 
amount of identifying information desirable). When an optimized 
reply is received at the communication server, a search of the 
appropriate client index (e.g., first the target unit, if also an active 
5 client, otherwise the client's or originating unit's indices) for the 
message identifier of the preceding message, indicating whether or 
not the preceding message has been deleted. When the preceding 
message's identifier is present, the process continues as noted 
above, in other words by sending the optimized reply to the target 
]() unit, or reconstructing the reply message and forwarding it to the 
target unit. 

Replies being sent to the client can similarly use an optimized 
reply to minimize messaging sizes. Thus, for example, where a reply 
is received by the communication server which has the client as an 

15 addressee, the communication server is capable of generating a delta 
between the reply message and a preceding message known to be 
stored in a mail database (e.g., memory 214 of FIG. 2) of the client. 
The preceding message is most easily identified if an additional 
identifier is included with the reply for ease of searching in the 

20 client's index. However, where such is not included, identifiers can 
be extracted from the text (e.g., author, date, recipient, subject) for 
comparison matching. Alternatively, a comparison of the text of the 
reply message can be used in determining the preceding message. For 
example, a series of preceding messages could be retrieved for 

25 textual comparison; or alternatively an identifying value for all or 
selected (e.g., sent) mail can be maintained (e.g., by calculating the 
text CRC value and storing it in the index), and a check of selected 
portions (e.g., all portions below insertions identifying preceding 
messages in the text) of the reply message text can then be 

30 performed. The latest or largest matching preceding message is the 
selected (which could be either a message sent to, or sent from, the 
client), so as to minimize the delta, and the delta calculated between 
the preceding message and the reply message. An optimized reply is 
then formed including the delta and preceding message identifier 
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recognizable by the client. This optimized reply is then forwarded, 
and reconstructed at the client into the reply message. In other 
words, the client retrieves from memory the message corresponding 
to the message identifier, and forms a replica of the reply message 
from the delta and message. Once acknowledged, both client and 
communication server indices are appropriately updated to reflect 
the mail transfer (steps 918-930). 

This embodiment thus provides an efficient process for 
sending reply data between a client and the communication server, 
without requiring the costly transfer of earlier transmitted portions 
of the reply data. 

In a final embodiment, a rate governor is provided so as to 
assist clients in maintaining their messaging and expenses within 
desired limits. Turning to FIG. 10, with reference also to FIG. 2, one 
embodiment of such a rate governor is illustrated. This rate 
governor operates to track the approximate time and/or expense for 
client use, which can be as simple as timing a circuit-switched 
connection, or where packet data is being sent, timing (or estimating 
based on size) the time and/or cost of transmitting the packet over 
the tariffed network(s). In estimating the transmission value (e.g.. 
cost), a rate governor could better estimate actual costs by taking 
into account known pricing factors established by each network 
service provider (e.g., rates by time of day, by grade/ quality of 
service (QoS) for packets, by size or bandwidth desired, etc.). These 
values would be maintained for application by the rate governor (234 
of FIG. 2) as -each data unit is received to determine an estimated 
transmission value. 

In the illustrated case of an email application, upon receiving a 
client-generated message the QM (or other appropriate controller 
entity of the communication server) passes the pertinent packet 
information or message parameter (e.g., the packet size from the 
header) to the rate governor, which in this case operates as a packet 
rate governor (or PRG). The PRG determines from the client object 
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(or profile store) the amount of use time and/or charge still 
available (or alternatively, the amount already used, and limits 
allowed), and compares the use time remaining (e.g., a previously 
authorized or allocated transmission value) against the value for the 
5 message parameter (step 954). 

Preferably several limits are established, including one or 
more alert thresholds. These alert thresholds would serve to warn 
the client each time a certain threshold is passed in amounts of 
time/charge used or remaining, permitting the client to limit use as 
10 needed to stay within budget, or to seek a higher limit in advance of 
the point at which the use limit is reached. This use or transmission 
limit serves as the budgeted limit for data transfers. Unless a user 
is privileged, once the use limit is reached further 

communications/data transfers are restricted. In the simplest form, 

15 such transfers are restricted by alerting the client that the use limit 
has been reached, terminating the current session and preventing 
further sessions until additional use limit time/charge is authorized. 
Alternatively, certain messaging could still be permitted (based, e.g., 
on any filterable criteria— e.g., permitting messages to the 

20 administrator but not a further communication unit), but with 

reminders that routine messages will not be forwarded. This would 
advantageously allow critical messages, messages to an 
administrator (e.g., requesting additional authorization), etc., to still 
be transferred, although it does not prevent a user from running up 

25 excess charges for messaging to the communication server. A PRG 
may thus also be advantageously used in the client (e.g., PRG 209 of 
FIG. 2), signaled by the PRG of the communication server to 
automatically set certain prestage filters to restrict all but certain 
message transfers until a new use limit is provided. If a user were 

30 to bypass this client ,PRG and continue improper messaging, all 

further sessions could be terminated by the communication server 
with notification to the administrator and client. 
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If the user is privileged, data transfers would still continue 
despite the user limit having been exceeded. However, an alert would 
still preferably be sent to both the client and administrator, 
allowing the administrator to verify the privilege and reset the use 
limit if desirable, and the client to still be aware it has passed a 
targeted use amount (steps 956-968 and 980-984). In any event, 
after each data transfer the client object or store is updated to 
reflect the new estimated transaction total (e.g., time remaining, 
total expense, etc.) (step 958). 

As mentioned above, if a user is not privileged it is preferable 
to allow the client an additional data transfer to an administrator 
requesting additional allocation of time/ charges. This request 
would be forwarded by the communication server to the 
administrator host, where it would be processed for approval. If 
approved, the administrator would notify the communication server 
to adjust the use limit by a specified amount. Alternatively, if there 
is no system administrator, but charges or debits are handled through 
a communication server service provider, the client may send any 
appropriate authorization for additional charge/debit to the 
communication server (e.g., by sending an encrypted account number 
and identifying information like a PIN (personal identification 
number). Once the charge or debit is processed and approved to the 
service provider's satisfaction, the amount of charge or debit would 
be used to adjust the use limit. A notification would also be 
forwarded to the client of the new use limit, with the client PRG 
being updated, accordingly (steps 970-978). 

In addition to updating the use limit in response to a user or. 
administrator request, the rate governor can also be advantageously 
set to automatically update the use limits upon the occurrence of a 
predetermined update event. Thus, for example, where billing and 
budgeting is done on a monthly cycle, and the administrator has set 
rate governor preferences so as to automatically reset the use limit 
on the first day of the next billing cycle, the communication server 
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will automatically reset the client use limit at the specified time 
and in the specified amount (step 992). 

Moreover, in order to achieve an even more accurate billing 
control, the communication server could be coupled with the tariffed 
5 network service provider(s) so as to receive periodic charge 

statements for client data traffic, as well as updates for. tariff 
rates, etc. In order to take advantage of these statements, a billing 
index would be maintained for each client estimating use and charges 
for each data transfer. Upon receiving the periodic charge statement 

K) (e.g., forwarded once a day during an administrative window) the 
estimated use entries are replaced by the actual use and charges 
from the statement, and the client profile (and object, it active) is 
updated to reflect a corrected use limit, etc. The administrator is 
notified, and the client is notified upon the next transaction, of the 

15 updated amount. If desired, the client or administrator can request a 
download of the current billing index showing the most recent 
estimated and actual charges (steps 986-990). 

Finally, one should appreciate that the above process is equally 
applicable to groups as well as to individual clients. Thus, the PRG 

20 can advantageously be used to set use limits for groups and 

supergroups of users, as well as for individual clients as described 
above. Thus, where one of the applications being used is groupware, 
as opposed to the email example described above, different groups 
can be assigned group use limits for groupware data transfers 

25 (while retaining individual use limits for separate email or data 
transfers, etc.). To avoid one or two users exhausting the group's 
authorized limit, individual use limits can still be set for each 
client, although with more flexibility, e.g., to draw on unused group 
time before requiring additional allocation from an administrator, to 

30 permit another user of the group to yield a portion of its individual 
use limit, etc. As should be apparent, many variations exist on how 
the rate governor is structured, depending on the applications being 
used, clients and groups operating, the interactivity with service 
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providers, complexity or simplicity desired, and many other related 
and unrelated factors. 

One skilled in the art will appreciate that there are many 
variations that are possible for the present invention, only a limited 
number of which have been described in detail above. Thus, for 
example, while the embodiments above describe application to 
clients communicating in certain systems, one should appreciate that 
it has application to any communication system, wired or wireless, 
client-server, distributed or other networks, etc.. in which the user 
is remote from a host. It can also be used with almost any 
application program or groups of programs (e.g., transferring 
database, wordprocessing, graphics, voice etc. files, executing 
programs and control messages, etc.). not just email or groupware. 
Moreover, while processor 206, controller 229, timers 205 and 224. 
data stores 211 and 225, and other circuits, are described in terms 
of specific logical/functional/circuitry relationships, one skilled in 
the art will appreciate that such may be implemented in a variety of 
ways, preferably by appropriately configured and programmed 
processors, ASICs (application specific integrated circuits), and 
DSPs (digital signal processors), but also by hardware components, 
some combination thereof, or even a distributed architecture with 
individual elements physically separated but cooperating to achieve 
the same functionality. Thus, it should be understood that the 
invention is not limited by the foregoing description of preferred 
embodiments, but embraces all such alterations, modifications, and 
variations in accordance with the spirit and scope of the appended 
claims. 
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We claim: 

Claims 

5 

1 . A system for controlling communications with a 
communication unit (201) comprising: 

a communication server (220), in communication with 
10 the communication unit, characterized by a data transfer 

manager (229) operable for communicating data between the 
communication unit and a host server, the data transfer 
manager comprising a rate governor (234, 209) for estimating 
a transmission value for data communicated between the 
15 communication server and communication unit, and comparing 
the estimated transmission value with an allocated 
transmission value. 

2. The system of claim 1 , wherein the rate governor is 

20 further operable for preventing communication of further data 
between the cornmunication server and communication unit 
when the estimated transmission value exceeds the allocated 
transmission value. 

25 3. The system of claim 1, wherein the communication 

server is ir* communication with the communication unit via at 
least a first communication channel, the first communication 
channel including a charge-bearing channel portion of a first 
communication service provider different from a second 

30 service provider of the communication server, the allocated 
transmission value corresponding to a total remaining 
transmission value authorized for the communication unit; and 
the rate governor is further operable for alerting the 
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communication unit when the allocated transmission value 
becomes less than a first threshold. 

4. The system of claim 1, wherein the data transfer 
manager further comprises a client profile store for storing 
the allocated transmission value, and the rate governor is 
further operable for updating the allocated transmission value, 
in response to a first data unit having an estimated first 
transmission value, by subtracting the estimated first 
transmission value from the allocated transmission value to 
obtain an updated allocated transmission value, and replacing 
the allocated transmission value in the client profile store 
with the updated allocated transmission value. 

5. The system of claim 1, wherein the data transfer 
manager further comprises a client profile store for storing 
the allocated transmission value, the data comprises plural 
data units and the estimated transmission value comprises an 
estimated total transmission value for the plural data units, 
and the rate governor is further operable for updating the 
allocated transmission value, in response to a further data unit 
having an estimated further transmission value, by adding the 
further estimated transmission value and estimated total 
transmission value to form an updated estimated total 
transmission value, and determining if the updated estimated 
total transmission value is greater than the allocated 
transmission - value. 

6. The system of claim 5, further comprising an 
administrator host server in communication with the 
communication server, wherein the rate governor is further 
operable to alert the administrator host server when the 
updated estimated total transmission value is greater than the 
allocated transmission value, and if the communication unit is 
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not privileged, prohibit further communication with the 
communication unit except to predetermined addressees. 

7 The system of claim 1, further comprising a host server 
5 in communication with the communication server, wherein the 
data transfer manager further comprises a virtual session 
manager adapted to control communication of data between the 
communication unit and host server by communicating the data 
via a sessionless-oriented communication protocol over a first 
10 communication channel between the virtual session manager 
and the communication unit, and by communicating the data via 
a session-oriented communication protocol between the 
virtual session manager and the host server. 

15 8. A method of controlling communications with a 
communication unit (201) comprising: 

at a communication server (220) in communication with 
the communication unit via a first communication channel, 

20 

receiving a first data unit, the first data unit being 
communicated between the communication unit and a further 
communication unit; characterized by 

estimating a transmission value for the first data unit, 
and comparing the estimated transmission value with a 
transmission limit to determine whether to allow 
communication of further data units between the 
communication unit and the communication server. 

9. The method of 'claim 8, wherein: 

step (b) further comprises at least one of: 



25 
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sending a notifier message to the communication unit 
when the transmission limit is less than a predetermined 
threshold value; 

preventing communication of further data units via the 
communication server when the estimated transmission value 
exceeds the transmission limit; 

determining an estimated total transmission value from 
the estimated transmission value and prior estimated 
transmission values for prior data units communicated 
between the communication unit and communication server, 
and sending a notifier message to the communication unit when 
the estimated total transmission value exceeds a 
predetermined threshold; and 

determining an estimated total transmission value from 
the estimated transmission value and prior estimated 
transmission values for prior data units communicated 
between the communication unit and communication server, 
and preventing communication of further data units via the 
communication server when the estimated total transmission 
value exceeds the transmission limit. 

10. A communication server characterized by a data transfer 
manager (229) operable for communicating data with a 
communication unit (201), the data transfer manager 
comprising a rate governor (234, 209) for estimating a 
transmission value for data communicated between 
communication unit and a further communication unit, and 
comparing the estimated transmission value with a 
transmission limit to determine whether to permit further 
communications with the communication unit via the 
communication server. 
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11. The communication server of claim 10, wherein the rate 
governor is further operabie for at least one of: 

preventing communication of further data between the 
communication server and communication unit when the 
5 estimated transmission value exceeds the transmission limit; 

determining an estimated total transmission value from 
the estimated transmission value and prior estimated 
transmission values for prior data communicated between the 
communication unit and communication server, and preventing 
K) communication of further data units via the communication 
server when the estimated total transmission value exceeds 
the transmission limit; and 

determining an estimated total transmission value from 
the estimated transmission value and prior estimated 
15 transmission values for prior data communicated between the 
communication unit and communication server, and sending a 
notifier message to the communication unit when the 
estimated total transmission value exceeds a predetermined 
threshold. 

20 

12. The communication server of claim 10, wherein the data 
transfer manager further comprises a virtual session manager 
adapted to control communication of data between the 
communication unit and a host server by communicating the 

25 data via a sessionless-onented communication protocol over a 
first communication channel between the virtual session 
manager and the communication unit, and by communicating the 
data via a session-oriented communication protocol between 
the virtual session manager and the host server. 



30 



WO 97/22936 PCT/US96/I9689 



1/8 




WO 97/22936 PCT/US96/1 9689 




WO 97/22936 



PCT/US96/19689 



MS/CLIENT 



INSTANTIATION 



± 



301 



3/8 
VSM 



303 



HOST/SERVEFHE.a. 
POST OFFICE) 



SEND REGISTRATION 



RECEIVE REGISTRATION 



302 



ACK 



304 



AUTHENTICATION; 
SEND REGISTRATION/ 
LOGON TO HOST 



RECEIVE REGISTRATIONl 
AUTHENTICATE I 



305 



J 



INSTANTIATION 



308^ 



± 



RECEIVE REG.;FULLY 
OUALIFIED.START TIMER 



SEND REGISTRATION 

i 

FULLY QUALIFIED;START\ 
TIMER 



r 



306 
307 



309 



324 



VIRTUAL SESSION ESTABLISHED 

320 



■SESSION ESTABLISHED- 



321 



QUERRY FOR MAIL 



H. 



RECEIVE NEW MAIL 
FORMS 



RECEIVE MAIL 
ACKNOWLEDGE 



UPDATE TIMER 



RECEIVE MAIL, 
FORWARD TO CLIENT 



y — \fqrward MAIL TO VSM \ 



■323 



327- 



ACKNOWLEDGE TO 
SERVER 



32 



H 



322 

UPDATE POST OFFICE 
BOX(E.G., MARK READ) 



326 



} 



UPDATE TIMER 



331 



328 



-332 




330 



OTHER DATA EXCHANGE\ 



FIG. 3 



-341 



LOGOFF CLIENT 



WO 97/22936 



PCT/US96/19689 



MS/CLIENT 



416 



RECEIVE MAIL; 
ACKNOWLEDGE 



4/8 

COMM SERVER 



QUERRY OBJECT 
FOR MAIL 



406- 



.414 



RECEIVE QUUFYING 
MAIL;FORWARD 



HOST/SERVER 




APPLY FILTERS; I 
SEND QUALIFYING MAILl 



RECEIVE MAIL; 
ACKNOWLEDGE 



.430 



APPLY FILTERS 

JL 



420- 



GENERATE MAIL 



RECEIVE MAIL 
APPLY FILTERS 



FOWARDMAIL 



418 



FORWARD QUALIFYING 
MAIL 



432 



434 



FORWARD QUALIFYING 
MAIL ATTACHMENTS; 
RETAIN; ALL UN- 
OUALIFIED MAIL 



I 



438 
y 



USER OVERRIDE, SEND 
UNQUALIFIED MAIL 



442 



CHANGE FILTER 
SETTINGS 



ACK 



422 



ACKNOWLEGE 
(LIST QUALIFYING, 
UNQUALIFIED MAIL) 



428 



MARK INDEX 



.436 



FOWARDMAIL 



1 



FOWARDMAIL 



.440 

1 



♦ • • 



444 



RECEIVE; 

ADJUST CLIENT 
PROFILE/OBJECT 



FIG.4 



WO 97/22936 



PCT/US96/19689 




FIG.6 



WO 97/22936 PCT/US96/19689 



MS/CLIENT 



720 



RECEIVE; UPDATE 
CLIENT SUMMARY 
INDEX, PROMPT USER 



722- 



USER REQUESTS 
SPECIFIED MAIL;SEND 
REQUESTfE.G., 
SERIAL NO.) 



730 



RECEIVE MAIL; 
ACKNOWLEDGE, 
UPDATE INDEX 



6/8 

COMM SERVER 



HOST/SERVER 



SEND QUERRY OBJECT^ 

702-^ 704 



RECEIVE QUERRY 
APPLY FILTERS 




SEND QUALIFYING MM 



3 



710 



714- 



RECEIVE ID INFO, SAVi 
IN SUMMARY INDEX 



1 



CAVlUHk lULNIIhYINO 

INFORMATION FOR 
EACH NON-QUALIFYING 
MAIL, SEND 



WAIT PREDETERMINED] 
PERIOD? I 



712- 



716- 



I 



MARK QUALIFYING ANDi 
NON-QUALIFYING MAIL I 



DETERMINE CLIENT 
SUMMARY INDEX CON- 
TENT SEND SUMMARY 
INDEX DELTA 



718 



724 



RECEIVE REQUEST, 
. FORWARD OBJ; 
TO POST OFFICE 



RECEIVE FORWARD 
TO CLIENT 



726 



RETRIEVE SPECIFIED 
MAIL. FORWARD 



728 



^_J UPDATEINDEX. SEND 
^ ACKNOWLEDGEMENT 



732 



■734 



MARK MAIL AS READ J 



FIG. 7 





^-801 


^802 


CLIENT 1 SUMMARY 
INDEX 


SERIAL NO. 1 


HEADER INFO. 1 (E.G.,AUTHOR:SUBJECT,DATE/TIME IN; 

SIZE:ACKNOWLEDGEMENT/SIZE:PRIORITYi 




SERIAL N0.2 


HEADER INFO 2 




• 

• 


• 
• 
• 



FIGS 



WO 97/22936 PCT/US96/I9689 



MS/CLIENT 



902 



7/8 

COMM SERVER 



HOST/SERVER 



FORM REPLY (NEW 
CONTENT) 



904 



GENERATE OPTIMIZED 

REPLY="DELTA" BET- 
WEEN REPLY AND A 

PREEDING MESSAGE, 
AND PRECEEDING 

MESSAGE IDENTIFIER 



906 



COMPARE OPTIMIZED 
REPLY AND STANDARD 

REPLY.SEND SHORT 
-FST 



RECEIVE OPTMIZED 
REPLY 



908. 



REQUEST PRECEEDING 
MESSAGE CORRESPO- 
NDING TO PRECEEDING\ 
MSS.ID 



910 



RECONSTRUCT REPLY 
USING DELTA AND PRE- 
CEEDING MESSAGE 



912 



RETRIEVE PRECEEDING 
MESS A G E S;SEND 
TO COMM SERVER 



914 



SEND REPLY TO 
ADDRESSEE 



pa 

^918 



920 



RECEIVE REPLY 
FOR CLIENT 



COMPARE REPLY TO 
PROCEEDING MESSAGE 
TO SOURCE/ADDRESSOF 
FROM CLIENT0N INDEX) 
FOR CONTENT MA TCH 



GENERATE OPTIMIZED 
REPLY=DELTA 
PLUS PRECEEDING 
MESSAGE IDENTIFIER 



-926 



RECONSTRUCT REPL Y [SEND OPTIMIZED REPL 
1 ' 



-922 
924 



UPDATE INDEX; 
ACKNOWLEDGE, 



H 



930 



928 



UPDATE INDEX, ETC. 



FIG.9 



WO 97/22936 



PCT/US96/19689 



MS/CLIENT 



8/8 

COMM SERVER 



ADMIN/SERVER 




958 



ALERT CLIENT USE LIMIT 
REACHED 



^970 



FORWARD NOTIFIER T* 
CLIENT, (OPTIONALLY) 
ADMINISTRATOR 



3 



UPDATE CLIENT OBJECT/ 
DATA BASE REFLECTING 
NEW TRANSACTION TOTAL\ 
(ESTIMA TED), DETERMINE 
NEW USE LIMIT 



OPTIONALLY (IF CAPABLE) 

1) SEND REQUEST TO 
ADMINISTRATOR FOR 

ADDITIONAL ALLOCATION 

2) AUTHORIZE COMM. 
SERVER PROVIDER FOR 

ADDITONAL CHARGE 
/DEBIT 



1) FORWARD REQUEST 
TO ADMINISTRATOR 

OR 

2) PROCESS CHARGE/ 
DEBIT AMOUNT, ADJUST 

LIMIT IF APPROVED 



^960 

FORWARD NOTIFIER TO 

ADMINISTRATOR OF 
ANY OVERRIDE; ALERT 
TO CLIENT 



'972 



UPDATE PRG USE LIMIT 



UPDA TE USE LIMILNOTt „ 
-TIFY CLIENT PRG, ETCjT~ 



962 



VERIFY PRIVILEGE; 
\ALERT ADMINISTRA TOi 



3 



■974 



r 

978 



PROCESS REQUEST FORM 
APPROVAL OF NEW LIMIT! 
NOTIFY COMM. SERVER | 




ALERT CLIENT 



FORWARD NOTIFIER T( 
CLIENT, (OPTION ALLLY)\ 
ADMINISTRATOR 



1 



988 



UPDATE PRG USE LIMIT, 
ALERT CLIENT 



990 



h 



CLIENT REQUEST 
DOWNLOAD OF CUR- 
RENT BILLING INDEX 



986 



RECEIVE BILLING INFOR 
-MATION FROM PROVIDER, 
REPLACE ESTIMATED USEl 
CHARGES IN BILLING 
ifiiDEX, UPDATE DIRECT 
OBJECT REFLECTING NEW\ 

TRANSACTION TOTAL, 
UPDATE USE LIMIT, NOTIFY 
CLIENT, ADMIN. 



UPDA TE EVENT OCCURS 

(E.G., START NEW 
BILLING CYCLE); ADJUST 
USE LIMIT.NOTIFY CLIENT 



-992 



FIG. 10 



V 



INTERNATIONAL SEARCH REPORT 



Jnlcmauonai iippucaium iV 
PCT/US96/ 19689 



A. ( I.ASSlrlt A 1 M>N Or SI'Rjrj 7 MA III K 
1PC(6) :G06F 13/00, 13/10 

US CL :379/58, 59; 364/284.4. 284.3; 455/33.1; 395/200.09. 200.12 
According u> liiicrnaiiDiial P-ilcut ChiMi'LalMii (IPC; ->r lu holh national vMaSMiK';iUi.n jiiJ IPC 


B. KIELDS SEARCHED 


Minimum documentation searched (classification system followed by classification symbols) 
U.S. 379/58. 59; 364/284.4. 284.3; 455/33.1; 395/200.09. 200.12 


Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 


Electronic data base consulted during the international search (name of data base and, where practicable, search terms used) 
APS, MAYA 


C. DOCUMENTS CONSIDERED TO BE RELEVANT 


Category* 


Citation of document, with indication, where appropriate, of the relevant passages 


Relevant to claim No. 


Y 


US 5,109,401 A {HATT0RI et al) 28 April 1992, Abstract; 
col. 5, line 38 - col. 6, line 47. 


1-12 


Y 


US 5,138,650 A (STAHL et al) 1 1 August 1992, 
Abstract; col. 4, line 8 - col. 6 line 40. 


1-12 


Y 


US 5,454,079 A (ROPER et al) 26 September 1995, col. 3, 
lines 22-44. 


1-12 


Y 


US 5,287,456 A (RHODES et al) 15 February 1994, col. 1, 
line 18 - col. 2 line 46. 


7 and 1 2 


| | Further documents arc listed in the continuation of Box C 


| ] Sec patent family annex. 




* Special ca tea ones of cited documents: 

"A " document defining the gene raj stale of tbc art which m oot considered 
to be part of particular relevance 

"li" earlier document published oa or after the international filing date 

*L* document which may throw doubts oa priority claimfO or which b 
cited in establish the publication dale of another citation or other 
special reason (as specified) 

"O" document referring to an oral disclosure, use. exhibition or other 
means 

"P" document published prior to the international filing dstr but Uter than 
the pnority date claimed 


*T* later document published after the tntcroauooaJ filing date or priority 
dale and not m conflict with the application bui cited to understand the 
principle or theory underlying the oivenboo 

"X" document of particular relevance: the claimed invention cannot he 
coos id c rod novel or cannot be considered to involve an invcnUve step 
when the document is taken alone 

*Y* document ol p*i*cuUr relevance; the claimed invention cannot tx. 

considered to tnvoKe an inventive step when the document u 
combined with one or more other »uch documents. «uch combination 
being obvious to a person tkUlod in the art 

*&" document member of the same patent family 


Dale of the actual completion of the international search 
26 FEBRUARY 1997 


Date of mailing of the international search report 

2 6 MAR 1997 


Name and mailing address of the ISA/US 
Commissioner of Patent* and Trademarks 
Box PCT 

Washington, D C. 202J1 
Facsimile No. <703> 305-3230 


Authorized 4 fficcc* 

Telephone No. (703) 305-9717 



Form PCT/ISA/210 (second shecttfJuly 1992)* 



